linux-stable.git/drivers/gpu/drm/mediatek, branch v6.11.2

drm/mediatek: Use spin_lock_irqsave() for CRTC event lock

2024-10-04T14:37:47+00:00

[ Upstream commit be03b30b7aa99aca876fbc7c1c1b73b2d0339321 ]

Use the state-aware spin_lock_irqsave() and spin_unlock_irqrestore()
to avoid unconditionally re-enabling the local interrupts.

Fixes: 411f5c1eacfe ("drm/mediatek: handle events when enabling/disabling crtc")
Signed-off-by: Fei Shao 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240828101511.3269822-1-fshao@chromium.org/
Signed-off-by: Chun-Kuang Hu 
Signed-off-by: Sasha Levin

drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()

2024-10-04T14:37:46+00:00

[ Upstream commit fe30bae552ce27b9fefe0b12db1544e73d07325f ]

In mtk_crtc_ddp_config(), mtk_crtc will use some configuration flags to
generate instructions to cmdq_handle, such as:
  state->pending_config
  mtk_crtc->pending_planes
  plane_state->pending.config
  mtk_crtc->pending_async_planes
  plane_state->pending.async_config

These configuration flags may be set to false when a GCE IRQ comes calling
ddp_cmdq_cb(). This may result in missing prepare instructions,
especially if mtk_crtc_update_config() with the flase need_vblank (no need
to wait for vblank) cases.

Therefore, the mtk_crtc->config_updating flag is set at the beginning of
mtk_crtc_update_config() to ensure that these configuration flags won't be
changed when the mtk_crtc_ddp_config() is preparing instructions.
But somehow the ddp_cmdq_cb() didn't use the mtk_crtc->config_updating
flag to prevent those pending config flags from being cleared.

To avoid missing the configuration when generating the config instruction,
the config_updating flag should be added into ddp_cmdq_cb() and be
protected with spin_lock.

Fixes: 7f82d9c43879 ("drm/mediatek: Clear pending flag when cmdq packet is done")
Signed-off-by: Jason-JH.Lin 
Reviewed-by: CK Hu 
Reviewed-by: Fei Shao 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240827-drm-fixup-0819-v3-1-4761005211ec@mediatek.com/
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240827-drm-fixup-0819-v3-2-4761005211ec@mediatek.com/
Signed-off-by: Chun-Kuang Hu 
Signed-off-by: Sasha Levin

Merge tag 'drm-misc-fixes-2024-09-05' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes

2024-09-06T01:25:46+00:00

A zpos normalization fix for komeda, a register bitmask fix for nouveau,
a memory leak fix for imagination, three fixes for the recent bridge
HDMI work, a potential DoS fix and a cache coherency for panthor, a
change of panel compatible and a deferred-io fix when used with
non-highmem memory.

Signed-off-by: Dave Airlie 

From: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20240905-original-radical-guan-e7a2ae@houat

drm/bridge-connector: move to DRM_DISPLAY_HELPER module

2024-09-03T08:18:31+00:00

drm_bridge_connector is a "leaf" driver, belonging to the display
helper, rather than the "CRTC" drm_kms_helper module. Move the driver
to the drm/display and add necessary Kconfig selection clauses.

Suggested-by: Maxime Ripard 
Acked-by: Maxime Ripard 
Signed-off-by: Dmitry Baryshkov 
Link: https://patchwork.freedesktop.org/patch/msgid/20240903-drm-bridge-connector-fix-hdmi-reset-v5-2-daebde6d9857@linaro.org
Signed-off-by: Maxime Ripard

drm/mediatek: Set sensible cursor width/height values to fix crash

2024-08-05T13:06:20+00:00

Hardware-speaking, there is no feature-reduced cursor specific
plane, so this driver reserves the last all Overlay plane as a
Cursor plane, but sets the maximum cursor width/height to the
maximum value that the full overlay plane can use.

While this could be ok, it raises issues with common userspace
using libdrm (especially Mutter, but other compositors too) which
will crash upon performing allocations and/or using said cursor
plane.

Reduce the maximum width/height for the cursor to 512x512 pixels,
value taken from IGT's maximum cursor size test, which succeeds.

Signed-off-by: AngeloGioacchino Del Regno 
Reviewed-by: Fei Shao 
Tested-by: Fei Shao 
Reviewed-by: Daniel Stone 
Reviewed-by: CK Hu 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240718082410.204459-1-angelogioacchino.delregno@collabora.com/
Signed-off-by: Chun-Kuang Hu

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

2024-07-05T09:36:25+00:00

Mediatek DRM Next for Linux 6.11

1. Convert to platform remove callback returning void
2. Drop chain_mode_fixup call in mode_valid()
3. Fixes the errors of MediaTek display driver found by IGT.
4. Add display support for the MT8365-EVK board
5. Fix bit depth overwritten for mtk_ovl_set bit_depth()
6. Remove less-than-zero comparison of an unsigned value
7. Call drm_atomic_helper_shutdown() at shutdown time
8. Log errors in probe with dev_err_probe()
9. Fix possible_crtcs calculation
10. Fix spurious kfree()

Signed-off-by: Daniel Vetter 
From: Chun-Kuang Hu 
Link: https://patchwork.freedesktop.org/patch/msgid/20240628134632.28672-1-chunkuang.hu@kernel.org

Merge v6.10-rc6 into drm-next

2024-07-05T08:47:28+00:00

The exynos-next pull is based on a newer -rc than drm-next. hence
backmerge first to make sure the unrelated conflicts we accumulated
don't end up randomly in the exynos merge pull, but are separated out.

Conflicts are all benign: Adjacent changes in amdgpu and fbdev-dma
code, and cherry-pick conflict in xe.

Signed-off-by: Daniel Vetter

drm/mediatek/dp: Fix spurious kfree()

2024-06-28T13:01:43+00:00

drm_edid_to_sad() might return an error or just zero. If that is the
case, we must not free the SADs because there was no allocation in
the first place.

Fixes: dab12fa8d2bd ("drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection")
Signed-off-by: Michael Walle 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Jani Nikula 
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20240604083337.1879188-1-mwalle@kernel.org/
Signed-off-by: Chun-Kuang Hu

drm/mediatek: dpi/dsi: Fix possible_crtcs calculation

2024-06-28T12:25:18+00:00

mtk_find_possible_crtcs() assumes that the main path will always have
the CRTC with id 0, the ext id 1 and the third id 2. This is only true
if the paths are all available. But paths are optional (see also
comment in mtk_drm_kms_init()), e.g. the main path might not be enabled
or available at all. Then the CRTC IDs will shift one up, e.g. ext will
be 0 and the third path will be 1.

To fix that, dynamically calculate the IDs by the presence of the paths.

While at it, make the return code a signed one and return -ENODEV if no
path is found and handle the error in the callers.

Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting possible_crtc way")
Suggested-by: Nícolas F. R. A. Prado 
Signed-off-by: Michael Walle 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240606092122.2026313-1-mwalle@kernel.org/
Signed-off-by: Chun-Kuang Hu

drm/mediatek: Log errors in probe with dev_err_probe()

2024-06-27T14:03:49+00:00

Use dev_err_probe() to log errors in the probe function of all drm
mediatek drivers. This avoids -EPROBE_DEFER return values from being
logged as errors, like the following:

  mediatek-disp-rdma 1c002000.rdma: Failed to add component: -517

As a side benefit it also standardizes the format of the error in the
log messages.

Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: CK Hu 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240606-mtk-disp-rdma-dev-err-probe-v2-1-3898621767b8@collabora.com/
Signed-off-by: Chun-Kuang Hu