linux/drivers/gpu/drm/mediatek, branch v6.19

Merge tag 'mediatek-drm-fixes-20260119' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes

2026-01-23T00:13:12Z

Mediatek DRM Fixes - 20260119 1. Fix platform_get_irq() error checking 2. HDMI DDC v2 driver fixes 3. dpi: Find next bridge during probe 4. mtk_gem: Partial refactor and use drm_gem_dma_object 5. dt-bindings: Fix typo 'hardwares' to 'hardware' Signed-off-by: Dave Airlie From: Chun-Kuang Hu Link: https://patch.msgid.link/20260119154717.4735-1-chunkuang.hu@kernel.org

drm/mediatek: mtk_gem: Partial refactor and use drm_gem_dma_object

2026-01-18T23:47:54Z

Partially refactor mtk_gem to stop using (and remove) the unneeded custom mtk_gem_obj structure and migrate drivers to use the API defined drm_gem_dma_object structure instead, and to align all of the functions to be similar to the logic from drm_gem_dma_helper. Unfortunately, for this driver it wasn't possible to directly use the drm_gem_dma_helper callbacks (apart from .print_info), as the DMA mapping here is done on specific dma devices instead of the main DRM device. Also, since the mtk_gem_obj structure is no more, also migrate the mtk_plane.c code to grab the DMA address from a drm_gem_dma_object and replace the inclusion of the custom mtk_gem.h header (as it is now unneeded) with the DRM API provided drm_gem_dma_helper. While at it, also set DRM_GEM_DMA_HELPER as an unconditional dependency (remove the `if DRM_FBDEV_EMULATION` from the select DRM_GEM_DMA_HELPER statement in Kconfig). This resolves an issue pointed by UBSAN, as when using drm_fbdev_dma the drm_gem_object is supposed to be child of a drm_gem_dma_object instead of a custom mtk_gem_obj (or the mtk_gem_obj should have been reordered to have the same fields as drm_gem_dma_object, but that would have been too fragile and generally a bad idea anyway). Fixes: 0992284b4fe4 ("drm/mediatek: Use fbdev-dma") Signed-off-by: AngeloGioacchino Del Regno Link: https://patchwork.kernel.org/project/dri-devel/patch/20251111085114.9752-1-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: dpi: Find next bridge during probe

2026-01-18T23:31:47Z

Trying to find the next bridge and deferring probe in the bridge attach callback is much too late. At this point the driver has already finished probing and is now running the component bind code path. What's even worse is that in the specific case of the DSI host being the last component to be added as part of the dsi_host_attach callback, the code path that this is in: -> devm_drm_of_get_bridge() mtk_dpi_bridge_attach() drm_bridge_attach() mtk_dpi_bind() ... component_add() mtk_dsi_host_attach() anx7625_attach_dsi() anx7625_link_bridge() - done_probing callback for of_dp_aux_populate_bus() of_dp_aux_populate_bus() anx7625_i2c_probe() _cannot_ return probe defer: anx7625 4-0058: [drm:anx7625_bridge_attach] drm attach mediatek-drm mediatek-drm.15.auto: bound 14014000.dsi (ops mtk_dsi_component_ops) mediatek-drm mediatek-drm.15.auto: error -EPROBE_DEFER: failed to attach bridge /soc/dpi@14015000 to encoder TMDS-37 [drm:mtk_dsi_host_attach] *ERROR* failed to add dsi_host component: -517 anx7625 4-0058: [drm:anx7625_link_bridge] *ERROR* fail to attach dsi to host. panel-simple-dp-aux aux-4-0058: DP AUX done_probing() can't defer panel-simple-dp-aux aux-4-0058: probe with driver panel-simple-dp-aux failed with error -22 anx7625 4-0058: [drm:anx7625_i2c_probe] probe done This results in the whole display driver failing to probe. Perhaps this was an attempt to mirror the structure in the DSI driver; but in the DSI driver the next bridge is retrieved in the DSI attach callback, not the bridge attach callback. Move the code finding the next bridge back to the probe function so that deferred probing works correctly. Also rework the fallback to the old OF graph endpoint numbering scheme so that deferred probing logs in both cases. This issue was found on an MT8183 Jacuzzi device with an extra patch enabling the DPI-based external display pipeline. Also tested on an MT8192 Hayato device with both DSI and DPI display pipelines enabled. Fixes: 4c932840db1d ("drm/mediatek: Implement OF graphs support for display paths") Signed-off-by: Chen-Yu Tsai Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20260114092243.3914836-1-wenst@chromium.org/ Signed-off-by: Chun-Kuang Hu

Revert "drm/mediatek: dsi: Fix DSI host and panel bridge pre-enable order"

2026-01-03T19:08:10Z

This reverts commit f5b1819193667bf62c3c99d3921b9429997a14b2. As the original commit (c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable")) causing the issue has been reverted, let's revert the fix for mediatek. Signed-off-by: Tomi Valkeinen Cc: stable@vger.kernel.org # v6.17+ Fixes: c9b1150a68d9 ("drm/atomic-helper: Re-order bridge chain pre-enable and post-disable") Reviewed-by: Maxime Ripard Reviewed-by: Linus Walleij Tested-by: Linus Walleij Signed-off-by: Linus Walleij Link: https://patch.msgid.link/20251205-drm-seq-fix-v1-2-fda68fa1b3de@ideasonboard.com

drm/mediatek: mtk_hdmi_ddc_v2: Fix multi-byte writes

2025-12-30T15:59:36Z

Currently, the mtk_hdmi_ddc_v2 driver sends a i2c message by calling the mtk_ddc_wr_one function for each byte of the payload to setup SI2C_CTRL and DDC_CTRL registers, and perform a sequential write transfer of one byte at a time to the target device. This leads to incorrect transfers as the target address (at least) is also sent each time. So, rename mtk_ddc_wr_one function to mtk_ddcm_write_hdmi to match the read function name (mtk_ddcm_read_hdmi) and modify its behaviour to send all payload data in a single sequential write transfer by filling the transfer fifo first then starting the transfer with a size equal to the payload size and not one anymore. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Louis-Alexis Eyraud Link: https://patchwork.kernel.org/project/dri-devel/patch/20251205-mtk-hdmi-ddc-v2-fixes-v1-2-260dd0d320f4@collabora.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: mtk_hdmi_ddc_v2: Add transfer abort on timeout cases

2025-12-30T15:54:09Z

During a read or write transfer, the mtk_hdmi_ddc_v2 driver polls the DDC_I2C_IN_PROG bit of HPD_DDC_STATUS register to check if the transfer completes but do no particular action if a timeout is reached. It could lead the next transfer attempts to fail because the faulty transfer was not aborted. So, add in both low level read and write functions a abort action by writing the DDC_CTRL register with the ABORT_XFER command value. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Louis-Alexis Eyraud Link: https://patchwork.kernel.org/project/dri-devel/patch/20251205-mtk-hdmi-ddc-v2-fixes-v1-1-260dd0d320f4@collabora.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: mtk_hdmi_v2: Fix return type of mtk_hdmi_v2_tmds_char_rate_valid()

2025-12-30T15:47:36Z

When building with -Wincompatible-function-pointer-types-strict, a warning designed to catch kernel control flow integrity (kCFI) issues at build time, there is an instance in the new HDMI v2 drm/mediatek code: drivers/gpu/drm/mediatek/mtk_hdmi_v2.c:1331:31: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(const struct drm_bridge *, const struct drm_display_mode *, unsigned long long)' with an expression of type 'int (const struct drm_bridge *, const struct drm_display_mode *, unsigned long long)' [-Werror,-Wincompatible-function-pointer-types-strict] 1331 | .hdmi_tmds_char_rate_valid = mtk_hdmi_v2_hdmi_tmds_char_rate_valid, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While 'int' and 'enum drm_mode_status' are ABI compatible, hence no regular warning from -Wincompatible-function-pointer-types, the mismatch will trigger a kCFI violation when mtk_hdmi_v2_tmds_char_rate_valid() is called indirectly. Update the return type of mtk_hdmi_v2_tmds_char_rate_valid() to be 'enum drm_mode_status' to clear up the warning and kCFI violation. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Nathan Chancellor Link: https://patchwork.kernel.org/project/dri-devel/patch/20251125-drm-mediatek-hdmi-v2-wifpts-v1-1-a6c7582cf69a@kernel.org/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: Fix platform_get_irq() error checking

2025-12-30T15:35:45Z

The platform_get_irq() function returns negative error codes on failure and positive non-zero IRQ numbers on success. It never returns NULL. Fix the error checking to look for negatives, and change "hdmi->irq" from unsigned int to just int. Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188") Signed-off-by: Dan Carpenter https://patchwork.kernel.org/project/dri-devel/patch/aSW0p5sqnJVJsqDO@stanley.mountain/ Signed-off-by: Chun-Kuang Hu

Merge tag 'mediatek-drm-next-20251120' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next

2025-11-21T08:48:28Z

Mediatek DRM Next - 20251120 1. Fix probe resource leaks 2. Add support for MT8195/88 HDMIv2 and DDCv2 3. Fix CCORR mtk_ctm_s31_32_to_s1_n function issue 4. Fix device node reference leak in mtk_dp_dt_parse() Signed-off-by: Dave Airlie From: Chun-Kuang Hu Link: https://patch.msgid.link/20251119233202.10034-1-chunkuang.hu@kernel.org

Merge tag 'v6.18-rc6' into drm-next

2025-11-20T22:55:08Z

Linux 6.18-rc6 Backmerge in order to merge msm next Signed-off-by: Dave Airlie