This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
Since GCE has been moved to MMINFRA in MT8196, all transactions from
MMINFRA to DRAM will have their addresses adjusted by subtracting a
mminfra_offset.
Therefore, the CMDQ helper driver needs to get the mminfra_offset value
of the SoC from cmdq_mbox_priv of cmdq_pkt and then add it to the DRAM
address when generating instructions to ensure GCE accesses the correct
DRAM address. CMDQ users can then call CMDQ helper APIs as usual.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This patch extends the cmdq_pkt_write API to support SoCs that do not
have subsys ID mapping by introducing new register write APIs:
- cmdq_pkt_write_pa() and cmdq_pkt_write_subsys() replace
cmdq_pkt_write()
- cmdq_pkt_write_mask_pa() and cmdq_pkt_write_mask_subsys() replace
cmdq_pkt_write_mask()
To ensure consistent function pointer interfaces, both
cmdq_pkt_write_pa() and cmdq_pkt_write_subsys() provide subsys and
pa_base parameters. This unifies how register writes are invoked,
regardless of whether subsys ID is supported by the device.
All GCEs support writing registers by PA (with mask) without subsys,
but this requires extra GCE instructions to convert the PA into a GCE
readable format, reducing performance compared to using subsys directly.
Therefore, subsys is preferred for register writes when available.
API documentation and function pointer declarations in cmdq_client_reg
have been updated. The original write APIs will be removed after all
CMDQ users transition to the new interfaces.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
When GCE executes instructions, it typically locates the corresponding
hardware register using the subsys ID. For hardware that does not
support subsys ID, the subsys ID is set to an invalid value, and the
physical address must be used to generate GCE instructions.
The main advantage of using subsys ID is to reduce the number of
instructions. Without subsys ID, an additional `ASSIGN` instruction
is needed to assign the high bytes of the physical address, which can
impact performance if too many instructions are required. However, if
the hardware does not support subsys ID, using the physical address
is the only option to achieve the same functionality.
This commit adds a pa_base parsing flow to the cmdq_client_reg structure
to handle hardware without subsys ID support.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add cmdq_get_mbox_priv() in cmdq_pkt_create() to ensure getting private
data before generating GCE instructions.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Acked-by: Jassi Brar <jassisinghbrar@gmail.com>
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The code, as it is, plays fast and loose with bandwidth units. It also
doesn't specify its constraints in the actual maximum hardware value,
but as some roundabout thing that then ends up multiplied into the
actual hardware value constraint after some indirections. In part, this
is due to the use of individual members for storing each limit, instead
of making it possible to index them by type.
Rework all of this by adding const array members indexed by the
bandwidth type enum to the soc_data struct. This array expresses the
actual hardware value limitations, not a factor thereof.
Use the clamp function macro to clamp the values between the minimum and
maximum constraints after all the calculations, which also means the
code doesn't write nonsense to a hardware register when the math is
wrong, as it'll constrain after all the calculations.
Pass the type as the actual enum type as well, and not as an int. If
there's some type checking that can be extracted from the function
signature, then we may as well use it.
Don't needlessly explicitly cast return values to the return type
either; this is both unnecessary and makes it harder to spot type safety
issues.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The DVFSRC has a clock on all platforms.
Get and enable it in the probe function, so that Linux's common clock
framework knows we're a user of it.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add support for the DVFSRC Version 4 by adding new functions for
vcore/dram levels (in v4, called gears instead), and for readout
of pre-programmed dvfsrc_opp entries, corresponding to each gear.
In the probe function, for v4, the curr_opps is initialized from
the get_hw_opps() function instead of platform data.
In order to make use of the new DVFSRCv4 code, also add support
for the MediaTek MT8196 SoC.
Co-developed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
In preparation for adding support for DVFSRC Version 4, add a new
`has_emi_ddr` member to struct dvfsrc_soc_data: if true, write the
DRAM bandwidth both to the BW_AVG and to the newly defined EMI_BW
register, present only on DVFSRC v4.
Currently supported SoCs will not use this, as has_emi_ddr is left
out from their platform data, hence reading false.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
In preparation for adding support for DVFSRC Version 4, add a new
callback for calculating the dram bandwidth, assign the current
calculation algo to all of the currently supported SoCs, and use
this in __dvfsrc_set_dram_bw_v1().
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
In preparation for adding support for DVFSRC Version 4, add a new
mtk_dvfsrc_bw_type enumeration, and propagate it from specific bw
setting callbacks to __dvfsrc_set_dram_bw_v1(), which will use it
to choose calculation multipliers and dividers in v4 callbacks.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
In preparation for adding support for DVFSRC Version 4, change the
error check for the MTK_SIP_DVFSRC_START command in the probe
function to error out only if BIT(0) is set: this is still valid
for the previous DVFSRC versions, as those always set this bit in
a fail reply anyway.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add an entry for the MT8371 SoC with commercial name Genio 520.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
In svs_enable_debug_write(), the buf allocated by memdup_user_nul()
is leaked if kstrtoint() fails.
Fix this by using __free(kfree) to automatically free buf, eliminating
the need for explicit kfree() calls and preventing leaks.
Fixes: 13f1bbcfb5 ("soc: mediatek: SVS: add debug commands")
Co-developed-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Jianhao Xu <jianhao.xu@seu.edu.cn>
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
[Angelo: Added missing cleanup.h inclusion]
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add an entry for the MT8391 SoC with commercial name Genio 720.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The MT8189 has a different socinfo match for MT8189 SoC
(commercial name Kompanio 540), so add it the driver.
Signed-off-by: Sirius Wang <sirius.wang@mediatek.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Make sure to drop the references taken by of_find_device_by_node() when
looking up the thermal sensor and opp devices during probe on probe
failure (e.g. probe deferral) and on driver unbind.
Fixes: 0bbb09b2af ("soc: mediatek: SVS: add mt8192 SVS GPU driver")
Cc: Roger Lu <roger.lu@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250909095651.5530-3-johan@kernel.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Make sure to drop the references taken by of_find_device_by_node() when
looking up the thermal sensor and opp devices during probe on probe
failure (e.g. probe deferral) and on driver unbind.
Fixes: 681a02e950 ("soc: mediatek: SVS: introduce MTK SVS engine")
Cc: Roger Lu <roger.lu@mediatek.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250909095651.5530-2-johan@kernel.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
The usage of MUTEX_MOD1 and MUTEX_MOD2 for calculating mod settings
over 32 has been confusing. To improve consistency and clarity, these
defines need to fit into the same MUTEX_MOD define as possible.
However, MUTEX_MOD1 cannot be directly used for all SoCs because,
for example, the mod1 register (0x34) of MT2712 is not adjacent to
its mod0 register (0x2c). To address this, a `mutex_mod1_reg` field
is introduced in the mutex driver data structure. This allows all
SoCs to use a unified MUTEX_MOD to determine their register offsets.
With this change, the separate usage of MUTEX_MOD1 and MUTEX_MOD2 is
eliminated, simplifying the logic for obtaining offsets and mod IDs.
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250624103928.408194-1-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
This structure was left unused by a previous patch:
drivers/soc/mediatek/mtk-dvfsrc.c:542:43: error: unused variable 'dvfsrc_bw_constr_mt8195' [-Werror,-Wunused-const-variable]
Fixes: b06785283e ("soc: mediatek: mtk-dvfsrc: Rename and move bw constraints data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250423162958.2223689-1-arnd@kernel.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add support for the MediaTek Dimensity 1200 (MT6893) SoC's DVFSRC
v2 hardware: the only difference between this and the only other
supported DVFSRCv2 SoC (MT8195) is the VCore-DRAM OPP array.
Link: https://lore.kernel.org/r/20250410144019.475930-6-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Rename the MT8183 and MT8195 bandwidth constraints data structure
to, respectively, dvfsrc_bw_constr_v1 and dvfsrc_bw_constr_v2, as
the actual constraints are depending on the DVFSRC version rather
than on the SoC.
While at it, to prepare for adding a new SoC, also move the two
structures at the start of the platform data code section.
Link: https://lore.kernel.org/r/20250410144019.475930-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The Mediatek Genio 1200 EVK P1V2 board has a different socinfo match
for MT8395 SoC (commercial name Genio 1200), so add it the driver.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250220-mtk-socinfo-genio-1200-evk-v1-1-a683ad028bc5@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Now that all of the mmsys routing tables have been fixed,
migrate all of them to use the MMSYS_ROUTE() macro: this
will make sure that future additions to any of the tables
for the currently supported SoCs are compile-time sanity
checked, greatly reducing room for (way too common) mistakes.
Link: https://lore.kernel.org/r/20250212100012.33001-8-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The mmsys driver reads the routing table and writes to the
hardware `val & mask`, but multiple entries in the mmsys
routing table for the MT8365 SoC are setting a 0x0 mask:
this effectively writes .. nothing .. to the hardware.
That would never work, and if the display controller was
actually working with the mmsys doing no routing at all,
that was only because the bootloader was correctly setting
the display controller routing registers before booting the
kernel, and the mmsys was never reset.
Make this table to actually set the routing by adding the
correct register masks to it.
While at it, also change MOUT val definitions to BIT(x), as
the MOUT registers are effectively checking for each bit to
enable output to the corresponding HW.
Please note that, for this SoC, only the MOUT registers are
checking bits (as those can enable multiple outputs), while
the others are purely reading a number to select an input.
Fixes: bc3fc5c051 ("soc: mediatek: mmsys: add MT8365 support")
Link: https://lore.kernel.org/r/20250212100012.33001-7-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The mmsys routing table for this SoC was effectively missing
initialization of the val variable of struct mtk_mmsys_routes:
this means that `val` was incorrectly initialized to zero,
hence the registers were wrongly initialized.
Add the required regval to all of the entries of the routing
table for this SoC to fix display controller functionality.
Fixes: 060f7875bd ("soc: mediatek: mmsys: Add support for MT8167 SoC")
Link: https://lore.kernel.org/r/20250212100012.33001-6-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Change the initialization data in the arrays of structure
mtk_mmsys_routes to make use of the MMSYS_ROUTE() macro:
this will make sure that each array entry's SEL value fits
in its corresponding register mask with a compile time check.
Link: https://lore.kernel.org/r/20250212100012.33001-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Every MediaTek SoC with multimedia capabilities has an array of
structure mtk_mmsys_routes that defines a multimedia connection
between hardware components.
This connection is activated by writing a (masked) value in each
specific register, and the association between from->to path and
value to write is expressed as an entry in that array.
Failing to set the right path does not give any meaningful error
and makes things to simply not work as the data will either not
be retrieved from the right input port, or will be written to
the wrong output port (or both): since a misconfiguration may
effectively still be a possibly correct configuration at the HW
level, this may be only giving side effects in terms of simply
getting no functionality but, again, no errors.
In order to reduce room for mistakes in declarations of the
mmsys routes, add a macro that compile-time checks that the
provided value does at least fit in the register mask.
Link: https://lore.kernel.org/r/20250212100012.33001-4-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The VDO1_MERGE4 hardware (merge5 software component) should be
set to enable output to DPI1_SEL by setting BIT(2) but, despite
the intention being exactly that, this won't work because the
declared register mask is wrong as it is set as GENMASK(1, 0).
Register MERGE4_MOUT_EN in VDO1 has four used bits [3, 0] so
fix the mask to reflect that.
That, in turn, allows the mmsys driver to actually set BIT(2)
in this register, fixing the MERGE4 output to DPI1 selection.
Fixes: c0349314d5 ("soc: mediatek: Support MT8188 VDOSYS1 in mtk-mmsys")
Link: https://lore.kernel.org/r/20250212100012.33001-3-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
MT8188 uses DPI1 to output to the HDMI controller: add the
Start of Frame and End of Frame configuration for the DPI1
IP to the tables to unblock generation and sending of these
signals to the GCE.
Link: https://lore.kernel.org/r/20250212100012.33001-2-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The recently introduced SoC attribute info rework avoided modifying the
machine attribut but still used it in the log message on successful SoC
matching. It leads to print a confusing log about a board-related info
(read from devicetree) and not about the matched SoC:
```
mtk-socinfo mtk-socinfo.0.auto: MediaTek MediaTek Genio-510 EVK SoC
detected
```
So, fix the dev_info format to display SoC family and name attribute
instead.
```
mtk-socinfo mtk-socinfo.0.auto: MediaTek Genio 510 (MT8370) SoC detected.
```
Fixes: da77c2d3d0 ("soc: mediatek: mtk-socinfo: Restructure SoC attribute information")
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Fei Shao <fshao@chromium.org>
Tested-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20250221-mtk-socinfo-fix-print-v1-1-20500f30ef66@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add an entry for the MT8390 SoC with commercial name Genio 700.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250113-mtk-socinfo_genio-510-700-v1-2-cf5112b325b7@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Add an entry for the MT8370 SoC with commercial name Genio 510.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250113-mtk-socinfo_genio-510-700-v1-1-cf5112b325b7@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
So far, the MediaTek socinfo driver populates the SoC information as
follows:
- family: "MediaTek"
- machine: "<marketing_name> (<soc_name>)"
e.g., "Kompanio 1380 (MT8195)"
- soc_id: <null>
This approach has some drawbacks:
1. "soc_id" can be used for showing the SoC name (e.g. "MT8195"), while
it's currently unused.
2. The newer socinfo API automatically populates the "machine"
attribute with the model name from board DTS if unspecified, which
we may want to preserve if possible.
3. "machine" combines the marketing name and SoC name, making it
trickier to parse. Ideally, the marketing name and SoC name should
be in separate attributes so userspace to utilize them as needed.
4. There's no guarantee that the marketing name will be announced along
with the SoC name. If either is undetermined, the current design
will result in a malformed "machine" output. This is observed on
some newer MediaTek platforms, where the marketing name is still
undetermined but the SoC information needs to be settled for device
registration and validation before launch.
To address these points, this commit proposes a new theme to display the
SoC information:
- family: "MediaTek <marketing_name>"
e.g., "MediaTek Kompanio 1380"
- machine: "<dt_model_name>" (auto-populated)
e.g., "Acer Tomato (rev1) board"
- soc_id: "<soc_name>"
e.g., "MT8195"
Moreover, if the marketing name is not provided, the driver displays
"MediaTek" in the "family" attribute instead, consistent with the
previous behavior.
Restructure the way driver populates the SoC information as described
above.
Note that Mediatek-based Chromebooks are the primary consumers of this
socinfo driver, and Google has prepared corresponding userspace changes
to comply with this update, so the impact to userspace is controlled.
Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20241219113411.3999355-1-fshao@chromium.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+QmuaPwR3wnBdVwACF8+vY7k4RUFAmeTNHEACgkQCF8+vY7k
4RWHRA//UI8B/q+/WHzqC5CCtySIvrabFvhQOFPR1GBwPBoASS0JwGuVFZcsJbjV
m6krBshs2OTwafVH8Sbxw6tlShG5hs7fe6hwhtokEnrL5uzfgYMxf7MpM0F2g8CR
1zTow17A7TDeUhdYDTmVbdcOb9rj5oFJCEOVsQXNaAu2jsDBGVZ1P7iUZTwIeyT+
r0uUzrlLylH4neIyXu6yBWXYCmXbQXtGHxkwe5GGxKMfqKwD83KK5gd4uUpiAyJe
tKW+gzZa/ngJaCQ+cr+8/z270h2vXeNohhC3c6Kq+/6pZgyEwUgyDTXT4nYVsUdd
1DeYiQekMUE3MwsKXPtFCyH3VGMvgMQK9fc+N10KC8wj+uCaqi59une8Yz3Ck89m
tIE9R9EwBWiyAmSKEBVZAJJjOKi5TBC1lOw+RUUjnjwVG34gZhe/ML8IyWI8OcAH
nEHb8BGwWHpoO7M5bmtzSbjAhgxzizzCclp1aEIzTlAbtC+1YXd96qJxzG5qjUrA
uO0PvwghFjjiZKDU9Iwsk9q83VMCva3IX9pondmefC5OZvgR5xG/L6H5JfwRotOa
XlRLj80/Pmn+PqvHxHJYqHkp9ujqiGbq6b0PJYU7FjiyghDGV7+urHuvmT+sdLo8
+nzch/NbZDf2WFxENZOzAOSYKYbahcp3dqkiOwTU1Iu23ERkSws=
=ktuX
-----END PGP SIGNATURE-----
Merge tag 'media/v6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
- Sensor driver fixes
- remove dead TI wl128x FM radio driver
- Add support for the imx462 sensor at the IMX290 binding
- V4L2 pixel data transmitter and receiver documentation improvements
- Add support for MIPI Discovery and Configuration for C-PHY line
orders
- imx8-isi fixes and improvements
- stm32: dcmipp: add core support for the stm32mp25
- qcom: camss: Add sc7280 support
- Various fixes and enhancements
* tag 'media/v6.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (152 commits)
media: nuvoton: Fix an error check in npcm_video_ece_init()
media: dvb-usb-v2: af9035: fix ISO C90 compilation error on af9035_i2c_master_xfer
media: platform: rzg2l-cru: rzg2l-video: Fix the comment in rzg2l_cru_start_streaming_vq()
media: fix secfeed undefined when filter alloc fail
media: dt-bindings: trivial white-space and example cleanup
MAINTAINERS: repair file entry in MEDIA DRIVERS FOR STM32 - CSI
media: solo6x10: Use const 'struct bin_attribute' callback
media: saa7164: Remove unused values
staging: media: imx: fix OF node leak in imx_media_add_of_subdevs()
media: platform: exynos4-is: Remove unused __is_get_frame_size
media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
media: mmp: Bring back registration of the device
media: cec: include linux/debugfs.h and linux/seq_file.h where needed
Revert "media: qcom: camss: Restructure camss_link_entities"
media: venus: Remove unused hfi_core_ping()
media: dt-bindings: qcom-venus: Deprecate video-decoder and video-encoder where applicable
media: venus: Populate video encoder/decoder nodename entries
media: venus: Add support for static video encoder/decoder declarations
media: venus: match instance creation and destruction order
media: venus: destroy hfi session after m2m_ctx release
...
These are changes to SoC specific drivers and DT bindings that don't have
a separate subsystem tree, or that get grouped here for simplicity.
Nothing out of the ordinary for the 6.14 release here:
- Most of the updates are for Qualcomm specific drivers, adding support
for additional SoCs in the exssting drivers, and support for wrapped
encryption key access in the SCM firmware.
- The Arm SCMI firmware code gains support for having multiple
instances of firmware running, and better module auto loading.
- A few minor updates for litex, samsung, ti, tegra, mediatek, imx and
renesas platforms.
- Reset controller updates for amlogic, to add support for the A1 soc
and clean up the existing code.
- Memory controller updates for ti davinci aemif, refactoring the code
and adding a few interfaces to other drivers.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeTgqUACgkQYKtH/8kJ
Uif73w/6A005eeovEmXLEUBMThlMpOLGeE5YL6arspQ2jvF93uh4vbJXn70xWn76
pV/1yzeu87E078mHBxcoQX0tb2Lt0xoueDBQ+jODxCcrr+6+0gPEPOq/VK7SBFH8
h1WrCeFjxmks3kyh0/8rQ4FebPClhkNT32RbQpbu+oP6n3uoKOvFgh5WxG29+hV/
6+lmzuMr7vWMnQ8KqPCX4tKPERkGE/68Gtq08SCH79K35dTVpMu6HadzURDssKdj
/SJW9rJhSZGOoYFHdOU5f2n1jRt2/Vg7snzujGFCY0pV7BW9tU/XzPV8YKU4wVx3
m0dlLCGDAN4I23TfhDJTDoEQXGU1dd4ISLf5LrbksQX9mfyZJB0hl0c9rCESuZkG
1Rt6CCgMNjSNDrqnoM2KDSwSF9mcczea6R/NDvYcU1jbX4gHZK91OuzD6AjI8OLm
1GcT8tmGPsUQElQYiSC+4rtsXBDg433p9WAnKLVH7xQ62mYzA2LQ6tvl2Cjua09z
LFNv5YD2oHNo3nI3zHFu+h/TKFJ+Tnq958mH575K54HgFfsGIv/eVvm3rXY3Tb8a
i+I41wHkGc5xuvTGgu3ZlwqC/a9cXo8jUoHPlp+c27U4VDUEkrlzRkIUaPgDZzBe
4DUCk8LTC+l0PKcOcdr5wwBArn0c4DDC+8rPnb27ZQoW0kC0GI8=
=oeUS
-----END PGP SIGNATURE-----
Merge tag 'soc-drivers-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC driver updates from Arnd Bergmann:
"These are changes to SoC specific drivers and DT bindings that don't
have a separate subsystem tree, or that get grouped here for
simplicity.
Nothing out of the ordinary for the 6.14 release here:
- Most of the updates are for Qualcomm specific drivers, adding
support for additional SoCs in the exssting drivers, and support
for wrapped encryption key access in the SCM firmware.
- The Arm SCMI firmware code gains support for having multiple
instances of firmware running, and better module auto loading.
- A few minor updates for litex, samsung, ti, tegra, mediatek, imx
and renesas platforms.
- Reset controller updates for amlogic, to add support for the A1 soc
and clean up the existing code.
- Memory controller updates for ti davinci aemif, refactoring the
code and adding a few interfaces to other drivers"
* tag 'soc-drivers-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (58 commits)
drivers/soc/litex: Use devm_register_restart_handler()
reset: amlogic: aux: drop aux registration helper
reset: amlogic: aux: get regmap through parent device
reset: amlogic: add support for A1 SoC in auxiliary reset driver
dt-bindings: reset: add bindings for A1 SoC audio reset controller
soc/tegra: fuse: Update Tegra234 nvmem keepout list
soc/tegra: Fix spelling error in tegra234_lookup_slave_timeout()
soc/tegra: cbb: Drop unnecessary debugfs error handling
firmware: qcom: scm: add calls for wrapped key support
soc: qcom: pd_mapper: Add SM7225 compatible
dt-bindings: firmware: qcom,scm: Document ipq5424 SCM
soc: qcom: llcc: Update configuration data for IPQ5424
dt-bindings: cache: qcom,llcc: Add IPQ5424 compatible
soc: mediatek: mtk-devapc: Fix leaking IO map on driver remove
soc: mediatek: mtk-devapc: Fix leaking IO map on error paths
firmware: qcom: scm: smc: Narrow 'mempool' variable scope
firmware: qcom: scm: smc: Handle missing SCM device
firmware: qcom: scm: Cleanup global '__scm' on probe failures
firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool()
firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available()
...
Error paths of mtk_devapc_probe() should unmap the memory. Reported by
Smatch:
drivers/soc/mediatek/mtk-devapc.c:292 mtk_devapc_probe() warn: 'ctx->infra_base' from of_iomap() not released on lines: 277,281,286.
Fixes: 0890beb226 ("soc: mediatek: add mt6779 devapc driver")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250104142012.115974-1-krzysztof.kozlowski@linaro.org
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The helper devm_clk_bulk_get_all_enable() missed to return the number of
clocks stored in the clk_bulk_data table referenced by the clks
argument and, therefore, will be dropped.
Use the newly introduced devm_clk_bulk_get_all_enabled() variant
instead, which is consistent with devm_clk_bulk_get_all() in terms of
the returned value:
> 0 if one or more clocks have been stored
= 0 if there are no clocks
< 0 if an error occurred
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241217-clk_bulk_ena_fix-v5-1-aafbbb245155@collabora.com
Acked-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In order to have fine-grained control, use cmdq_pkt_eoc() and
cmdq_pkt_jump_rel() to replace cmdq_pkt_finalize().
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This adds support for the MT8188 SoC in the MediaTek Regulator
Coupler driver, allowing stable GPU DVFS on this chip;
Moreover, this adds a new MediaTek DVFS Resource Collector (DVFSRC)
driver, allowing to enable other drivers (interconnect, regulator)
which can now communicate with the DVFSRC hardware.
Last but not least, this includes some cleanups for the CMDQ Helper
and MediaTek SVS drivers.
-----BEGIN PGP SIGNATURE-----
iJ4EABYKAEYWIQQn3Xxr56ypAcSHzXSaNgTPrZeEeAUCZyitDigcYW5nZWxvZ2lv
YWNjaGluby5kZWxyZWdub0Bjb2xsYWJvcmEuY29tAAoJEJo2BM+tl4R4h1wA/1xT
8kHN16gVzZ6JvjvzOeipCi2YPJ0LCPv4jpvEx4abAP9tFsyVYsQGAE0XS74p3GRT
r9NhhlV7dnpQmVO/SPClDQ==
=cgv/
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmcpQSMACgkQYKtH/8kJ
UieT8A/+LmbcqykZ8LJEvKwIE7zsXEX+Jru2Ani7XMr8hbRTTHS5YsQNaRG1EdqL
9rDtwhI5L+IK6hn9JDu2RoUF2avECirX2gf+OUiMXy7Cn4BN+lpoir1sImtgSBOz
zwNq2zLzEU2im/fCaL1uN8gzi8+dR0drX9LYyaghoBlv5RlNu+NE+lx3dIezaEaU
Plx9dhH2GpbvOp6zVD01Q+6uD3bR8ybvoCPpewWv8Jn3u3+M9qf1krXOHKRqT9Vp
ErFTF3aC2KBsAPVBHBXgx/uKx918KJIvLRHYh+a5KtstRBjGwpn0SKumNyogNF2I
czULW9UX7kwqrOR1pVnu+4C28vTj38syV3VWEZ/fYUxe283TPcr86YLcZhb3u6m8
I0JpN+DqTf+f6r6tY4PWm19aKBFmDNEerIz8f2ajQoZdT6yunV+LwBMfhGYZnESC
o96lZai4U+gd9XmEHxJlGQU5prfLob/hZ/NrYScCrOrQ7lX86+30M6jtEr5GwLNS
113IWzwSwSm6yqDmDiylm4Vmk6zCmjQuaZ2YMNpk7yfWX9Mw+rNWPawf3s5k4KVe
XP+Y0UOW3SzU8OXns0XCwNVTtJL0rPsh0zKwzLcqowrLuc3P+jJyYq58VgI3g58V
1nLpRBGhM5VD83c27/borOQYjk5IsTxHx2jttrdgO6qsQN5C1JM=
=GKpu
-----END PGP SIGNATURE-----
Merge tag 'mtk-soc-for-v6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into arm/drivers
MediaTek soc driver updates for v6.13
This adds support for the MT8188 SoC in the MediaTek Regulator
Coupler driver, allowing stable GPU DVFS on this chip;
Moreover, this adds a new MediaTek DVFS Resource Collector (DVFSRC)
driver, allowing to enable other drivers (interconnect, regulator)
which can now communicate with the DVFSRC hardware.
Last but not least, this includes some cleanups for the CMDQ Helper
and MediaTek SVS drivers.
* tag 'mtk-soc-for-v6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
soc: mediatek: mtk-svs: Call of_node_put(np) only once in svs_get_subsys_device()
soc: mediatek: mediatek-regulator-coupler: Support mt8188
soc: mediatek: mtk-cmdq: Move cmdq_instruction init to declaration
soc: mediatek: mtk-cmdq: Move mask build and append to function
soc: mediatek: Add MediaTek DVFS Resource Collector (DVFSRC) driver
dt-bindings: soc: mediatek: Add DVFSRC bindings for MT8183 and MT8195
Link: https://lore.kernel.org/r/20241104112625.161365-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/soc to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
On the way do a few whitespace changes to make indention consistent.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Herve Codina <herve.codina@bootlin.com> # for fsl/qe/{qmc,tsa}.c
Acked-by: Bjorn Andersson <andersson@kernel.org> # qcom parts
Acked-by: Gabriel Somlo <gsomlo@gmail.com>
Acked-by: Andrew Jeffery <andrew@codeconstruct.com.au> # aspeed
Link: https://lore.kernel.org/r/20241029074859.509587-2-u.kleine-koenig@baylibre.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
An of_node_put(np) call was immediately used after a pointer check
for a of_find_device_by_node() call in this function implementation.
Thus call such a function only once instead directly before the check.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/884f0a5d-e6d3-47dc-8a9e-201bb86b271f@web.de
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The Mali GPU in mt8188 also requires coupled power supplies,
that is, the "vsram" voltage should follow the "vgpu" voltage.
Therefore add the compatible to enable this coupling behavior.
Signed-off-by: Pablo Sun <pablo.sun@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20241002022138.29241-6-pablo.sun@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Move, where possible, the initialization of struct cmdq_instruction
variables to their declaration to compress the code.
While at it, also change an instance of open-coded mask to use the
GENMASK() macro instead, and instances of `ret = func(); return ret;`
to the equivalent (but shorter) `return func()`.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Move the CMDQ_CODE_MASK packet build and append logic to a new
cmdq_pkt_mask() function; this reduces code duplication by 4x.
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
The Dynamic Voltage and Frequency Scaling Resource Collector (DVFSRC) is a
Hardware module used to collect all the requests from both software and the
various remote processors embedded into the SoC and decide about a minimum
operating voltage and a minimum DRAM frequency to fulfill those requests in
an effort to provide the best achievable performance per watt.
This hardware IP is capable of transparently performing direct register R/W
on all of the DVFSRC-controlled regulators and SoC bandwidth knobs.
This driver includes support for MT8183, MT8192 and MT8195.
Co-Developed-by: Dawei Chien <dawei.chien@mediatek.com>
[Angelo: Partial refactoring and cleanups]
Reviewed-by: Georgi Djakov <djakov@kerenl.org>
Link: https://lore.kernel.org/r/20240610085735.147134-5-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
All of mutex_mod and mutex_table_mod contain an array of bit
numbers, which can go from 0 to 63, it is hence not needed to
use an unsigned 32-bits integer to store that: change them to
unsigned 8-bits instead.
As for the mutex_sof table since this directly contains the values
to write to the DISP_MUTEXn_CTL register, which has only bits [13:0]
(so this register is effectively 14 bits long), change that to use
unsigned 16-bits.
The type of mutex_{mod,sof}_reg was also changed to 16 bits, as
the maximum value that those will ever have is 0x800, because it
calculates as 0x30 + (0x20 * n) where n's maximum value is 63.
This reduces module size and brings no functional changes.
Before:
text data bss dec hex filename
9929 512 0 10441 28c9 mtk-mutex.o
After:
text data bss dec hex filename
7425 512 0 7937 1f01 mtk-mutex.o
Link: https://lore.kernel.org/r/20240729122538.989855-1-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
