linux-stable.git/drivers/soc/mediatek, branch v6.18

soc: mediatek: mtk-svs: fix device leaks on mt8192 probe failure

2025-09-10T09:48:56+00:00

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: 0bbb09b2af9d ("soc: mediatek: SVS: add mt8192 SVS GPU driver")
Cc: Roger Lu 
Signed-off-by: Johan Hovold 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://lore.kernel.org/r/20250909095651.5530-3-johan@kernel.org
Signed-off-by: Matthias Brugger

soc: mediatek: mtk-svs: fix device leaks on mt8183 probe failure

2025-09-10T09:48:56+00:00

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: 681a02e95000 ("soc: mediatek: SVS: introduce MTK SVS engine")
Cc: Roger Lu 
Signed-off-by: Johan Hovold 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://lore.kernel.org/r/20250909095651.5530-2-johan@kernel.org
Signed-off-by: Matthias Brugger

soc: mediatek: mtk-mutex: Fix confusing usage of MUTEX_MOD2

2025-06-25T13:59:00+00:00

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 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://lore.kernel.org/r/20250624103928.408194-1-jason-jh.lin@mediatek.com
Signed-off-by: AngeloGioacchino Del Regno

soc: mediatek: mtk-dvfsrc: remove an unused variable

2025-04-24T07:15:01+00:00

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: b06785283ec1 ("soc: mediatek: mtk-dvfsrc: Rename and move bw constraints data")
Signed-off-by: Arnd Bergmann 
Link: https://lore.kernel.org/r/20250423162958.2223689-1-arnd@kernel.org
Signed-off-by: AngeloGioacchino Del Regno

soc: mediatek: mtk-dvfsrc: Add support for Dimensity 1200 MT6893

2025-04-14T09:53:50+00:00

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

soc: mediatek: mtk-dvfsrc: Rename and move bw constraints data

2025-04-14T09:53:36+00:00

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

soc: mediatek: mtk-socinfo: Add extra entry for MT8395AV/ZA Genio 1200

2025-03-06T10:54:21+00:00

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 
Reviewed-by: AngeloGioacchino Del Regno 
Link: https://lore.kernel.org/r/20250220-mtk-socinfo-genio-1200-evk-v1-1-a683ad028bc5@collabora.com
Signed-off-by: AngeloGioacchino Del Regno

soc: mediatek: mt8188-mmsys: Add support for DSC on VDO0

2025-03-06T10:54:20+00:00

Add routing paths to support Display Stream Compression on the
VDOSYS0 pipelines ending with DSI or DisplayPort (DP_INTF).

Link: https://lore.kernel.org/r/20250212100012.33001-9-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno

soc: mediatek: mmsys: Migrate all tables to MMSYS_ROUTE() macro

2025-03-06T10:54:20+00:00

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

soc: mediatek: mt8365-mmsys: Fix routing table masks and values

2025-03-06T10:54:20+00:00

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: bc3fc5c05100 ("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