user/sven/linux.git/drivers/gpu/drm/mediatek, branch v6.9.12

drm/mediatek: Call drm_atomic_helper_shutdown() at shutdown time

2024-07-25T07:53:27Z

[ Upstream commit c38896ca6318c2df20bbe6c8e3f633e071fda910 ] Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart comes straight out of the kernel doc "driver instance overview" in drm_drv.c. This driver users the component model and shutdown happens in the base driver. The "drvdata" for this driver will always be valid if shutdown() is called and as of commit 2a073968289d ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop") we don't need to confirm that "drm" is non-NULL. Suggested-by: Maxime Ripard Reviewed-by: Maxime Ripard Reviewed-by: Fei Shao Tested-by: Fei Shao Signed-off-by: Douglas Anderson Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20240611102744.v2.1.I2b014f90afc4729b6ecc7b5ddd1f6dedcea4625b@changeid Signed-off-by: Sasha Levin

drm/mediatek: dp: Fix mtk_dp_aux_transfer return value

2024-06-12T09:39:28Z

[ Upstream commit 8431fff9e0f3fc1c5844cf99a73b49b63ceed481 ] In case there is no DP device attached to the port the transfer function should return IO error, similar to what other drivers do. In case EAGAIN is returned then any read from /dev/drm_dp_aux device ends up in an infinite loop as the upper layers constantly repeats the transfer request. Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by: Wojciech Macek Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240417103819.990512-1-wmacek@chromium.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin

drm/mediatek: Init `ddp_comp` with devm_kcalloc()

2024-05-30T07:44:45Z

[ Upstream commit 01a2c5123e27b3c4685bf2fc4c2e879f6e0c7b33 ] In the case where `conn_routes` is true we allocate an extra slot in the `ddp_comp` array but mtk_drm_crtc_create() never seemed to initialize it in the test case I ran. For me, this caused a later crash when we looped through the array in mtk_drm_crtc_mode_valid(). This showed up for me when I booted with `slub_debug=FZPUA` which poisons the memory initially. Without `slub_debug` I couldn't reproduce, presumably because the later code handles the value being NULL and in most cases (not guaranteed in all cases) the memory the allocator returned started out as 0. It really doesn't hurt to initialize the array with devm_kcalloc() since the array is small and the overhead of initting a handful of elements to 0 is small. In general initting memory to zero is a safer practice and usually it's suggested to only use the non-initting alloc functions if you really need to. Let's switch the function to use an allocation function that zeros the memory. For me, this avoids the crash. Fixes: 01389b324c97 ("drm/mediatek: Add connector dynamic selection capability") Signed-off-by: Douglas Anderson Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240328092248.1.I2e73c38c0f264ee2fa4a09cdd83994e37ba9f541@changeid/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin

drm/mediatek: Add 0 size check to mtk_drm_gem_obj

2024-05-30T07:44:44Z

[ Upstream commit 1e4350095e8ab2577ee05f8c3b044e661b5af9a0 ] Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Justin Green Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240307180051.4104425-1-greenjustin@chromium.org/ Signed-off-by: Chun-Kuang Hu Signed-off-by: Sasha Levin

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

2024-03-01T09:14:33Z

Mediatek DRM Next for Linux 6.9 1. Add display driver for MT8188 VDOSYS1 2. DSI driver cleanups 3. Filter modes according to hardware capability 4. Fix a null pointer crash in mtk_drm_crtc_finish_page_flip Signed-off-by: Dave Airlie From: Chun-Kuang Hu Link: https://patchwork.freedesktop.org/patch/msgid/20240229162143.28957-1-chunkuang.hu@kernel.org

drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip

2024-02-29T16:15:28Z

It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240223212404.3709690-1-hsinyi@chromium.org/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: Filter modes according to hardware capability

2024-02-27T00:02:55Z

We found a stability issue on MT8188 when connecting an external monitor in 2560x1440@144Hz mode. Checked with the designer, there is a function called "prefetch" which is working during VBP (triggered by VSYNC). If the duration of VBP is too short, the throughput requirement could increase more than 3 times and lead to stability issues. The mode settings that VDOSYS supports are mainly affected by clock rate and throughput, display driver should filter these settings according to the SoC's limitation to avoid unstable conditions. Since currently the mode filter is only available on MT8195 and MT8188 and they share the same compatible name, the reference number (8250) is hard coded instead of in the driver data. Signed-off-by: Hsiao Chien Sung Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240220093711.20546-2-shawn.sung@mediatek.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: dsi: Use mipi_dsi_pixel_format_to_bpp() helper function

2024-02-19T14:49:51Z

Instead of open coding, use the mipi_dsi_pixel_format_to_bpp() helper function from drm_mipi_dsi.h in mtk_dsi_poweron() and for validation in mtk_dsi_bridge_mode_valid(). Note that this function changes the behavior of this driver: previously, in case of unknown formats, it would (wrongly) assume that it should account for a 24-bits format - now it will return an error and refuse to set clocks and/or enable the DSI. This is done because setting the wrong data rate will only produce a garbage output that the display will misinterpret both because this driver doesn't actually provide any extra-spec format support and/or because the data rate (hence, the HS clock) will be wrong. Reviewed-by: Alexandre Mergnat Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240215085316.56835-10-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: dsi: Compress of_device_id entries and add sentinel

2024-02-19T14:48:22Z

All entries fit in 82 columns, which is acceptable: compress all of the mtk_dsi_of_match[] entries to a single line for each. While at it, also add the usual sentinel comment to the last entry. Reviewed-by: Alexandre Mergnat Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240215085316.56835-9-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu

drm/mediatek: dsi: Simplify with dev_err_probe and remove gotos

2024-02-19T14:46:46Z

Most of the functions that are called in the probe callback are devm managed, or all but mipi_dsi_host_register(): simplify the probe function's error paths with dev_err_probe() and remove the lonely instance of `goto err_unregister_host` by just directly calling the mipi_dsi_host_unregister() function in the devm_request_irq() error path, allowing to also remove the same label. Reviewed-by: Alexandre Mergnat Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: CK Hu Link: https://patchwork.kernel.org/project/dri-devel/patch/20240215085316.56835-8-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu