[PATCH v5 00/10] drm/msm: fix SMMU fault dumps
From: Dmitry Baryshkov
Date: Fri Oct 23 2026 - 19:26:01 EST
In several cases the drm/msm can cause an SMMU fault on modesetting (due
to the display controller still scanning the BO which is being
unmapped). Fix the cases which I stumbled upon, together with the issues
found while chasing them: hardware block pointers surviving the
reservation which handed them out.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
---
Changes in v5:
- Rebased on v3 of the KMS init series
- Keep the kernel-doc of dpu_crtc_check_mode_changed() on that function
rather than on the new helpers placed in front of it (W=1)
- Explain why msm_crtc_vblank_off() can release the pending framebuffers
straight away: the encoders have already stopped the timing engine
(Sashiko)
- Link to v4: https://patch.msgid.link/20261003-fd-kms-fix-smmu-v4-0-2a44d4d8ac77@xxxxxxxxxxxxxxxx
Changes in v4:
- Take the framebuffer pin lock with guard() instead of unwinding through
labels (Rob)
- Move the fixes of the KMS init error handling, including the unwind of
msm_drm_kms_init() from v3, to a separate series, which this one now
depends on
- Add a retired framebuffer to the pending list and schedule its release
under the same lock, so that msm_crtc_vblank_off() cannot free it in
between, and track whether the vblank is off next to the list rather
than reading crtc->state, which a later commit may have swapped (Sashiko)
- New patches, ahead of the DSPP and DSC ones: clear the CWB and CDM
pointers left by a previous reservation (Sashiko)
- New patch: flush the MDP5 interface before starting the timing engine,
otherwise the first frame after a re-enable is fetched from the
framebuffer scanned out before the disable (db820c)
- Link to v3: https://patch.msgid.link/20260912-fd-kms-fix-smmu-v3-0-a7ddc6fe2032@xxxxxxxxxxxxxxxx
Changes in v3:
- Initialise the framebuffer's lock and dirtyfb count before
drm_framebuffer_init() publishes the framebuffer (Sashiko)
- New patch: unwind msm_drm_kms_init() on failure rather than handing a
half-initialised kms to msm_drm_kms_uninit() (prompted by Sashiko)
- Drop the pin count from the deferred unpin work rather than from
->cleanup_fb(), so a framebuffer scanned out by several crtcs stays
pinned until the last of them has passed a vblank (Sashiko)
- Defer each retired framebuffer with its own drm_vblank_work, as i915
does for cursor framebuffers, instead of a per-crtc drm_flip_work: the
release no longer takes a detour through kms->wq, and nothing needs
setting up or tearing down in the kms init path
- Release the framebuffers still pending on a crtc by hand when its vblank
is switched off; its interface is already disabled by then, so no
further vblank arrives to run the work
- New patch: clear the DSC blocks left by a previous reservation, the same
bug as the DSPP one (Sashiko)
- Link to v2: https://patch.msgid.link/20260908-fd-kms-fix-smmu-v2-0-9391815742a8@xxxxxxxxxxxxxxxx
Changes in v2:
- New patch: lock the framebuffer pin state, it was updated locklessly
(Sashiko)
- Do not defer the release on an inactive crtc, it was leaked there
(Sashiko)
- Flush retired framebuffers from msm_drm_kms_uninit(), before kms->vm is
dropped, and only for crtcs which have a vblank work (Sashiko)
- Clean the flip works up after destroy_workqueue() (Sashiko)
- Fixed the long-standing issue of the msm driver roguely setting
allow_modeset, which started to manifest in timeouts and SMMU errors.
- Link to v1: https://patch.msgid.link/20260903-fd-kms-fix-smmu-v1-0-608d02491666@xxxxxxxxxxxxxxxx
To: Rob Clark <robin.clark@xxxxxxxxxxxxxxxx>
To: Dmitry Baryshkov <lumag@xxxxxxxxxx>
To: Abhinav Kumar <abhinav.kumar@xxxxxxxxx>
To: Jessica Zhang <jesszhan0024@xxxxxxxxx>
To: Sean Paul <sean@xxxxxxxxxx>
To: Marijn Suijten <marijn.suijten@xxxxxxxxxxxxxx>
To: David Airlie <airlied@xxxxxxxxx>
To: Simona Vetter <simona@xxxxxxxx>
To: Antonino Maniscalco <antomani103@xxxxxxxxx>
To: Kalyan Thota <quic_kalyant@xxxxxxxxxxx>
To: Federico Amedeo Izzo <federico@xxxxxxxx>
To: Helen Koike <helen.fornazier@xxxxxxxxx>
To: Vignesh Raman <vignesh.raman@xxxxxxxxxxxxx>
To: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
To: Maxime Ripard <mripard@xxxxxxxxxx>
To: Thomas Zimmermann <tzimmermann@xxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: freedreno@xxxxxxxxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
---
Dmitry Baryshkov (10):
drm/msm: serialise framebuffer pin state
drm/msm: fix framebuffer pin refcount leak on prepare failure
drm/msm: release scanout framebuffers only after a vblank
drm/msm/mdp5: flush the interface before starting the timing engine
drm/msm/dpu: clear the CWB blocks left by a previous reservation
drm/msm/dpu: clear the CDM block left by a previous reservation
drm/msm/dpu: clear the DSPP pointer when no DSPP is assigned
drm/msm/dpu: clear the DSC blocks left by a previous reservation
drm/msm/dpu: only reassign resources when the encoder is reprogrammed
drm/ci: mark pixel-format tests as passing on SC7180
.../xfails/msm-sc7180-trogdor-kingoftown-fails.txt | 2 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 36 +++++-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 23 ++--
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 4 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 4 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 3 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 2 +-
drivers/gpu/drm/msm/msm_atomic.c | 17 +--
drivers/gpu/drm/msm/msm_drv.h | 4 +-
drivers/gpu/drm/msm/msm_fb.c | 75 ++++++++---
drivers/gpu/drm/msm/msm_kms.c | 142 +++++++++++++++++++++
drivers/gpu/drm/msm/msm_kms.h | 19 +++
15 files changed, 276 insertions(+), 62 deletions(-)
---
base-commit: d024361c631b3f020a26c07d683e5103404b0fbf
change-id: 20260902-fd-kms-fix-smmu-2d4baaf460b0
prerequisite-change-id: 20260930-msm-kms-destroy-fixes-0f04b1d39b83:v3
prerequisite-patch-id: d7439e7df4daac116217eb0fbbc277974d8dc1c9
prerequisite-patch-id: c1e587e18e63a6d5e97326ea2d93f58bc109ea89
prerequisite-patch-id: fb2a9d3af5c8fd52a0a3907f20f6b90661664dcb
prerequisite-patch-id: ed404293463bd438758cb0d1ed48b0c4c6de161a
prerequisite-patch-id: 5519e2e012b2065c08849502118233ccfd61e9d3
prerequisite-patch-id: 09f7ca53872a2ab17488f2bb94a1c2cd4c396781
prerequisite-patch-id: 3bc29c32e4b7fa71b785e0f7b6e16aebacc5be60
prerequisite-patch-id: 63305cbd316626057e69ebafd6689daf10f2d2d8
prerequisite-patch-id: 11dc97f7f4980bdad49123271651749d0a8f8d23
prerequisite-patch-id: 79bb5b490e30ed65caaace15d025974ada206d86
prerequisite-patch-id: a1d0abc303bb5730ac9901a29d678db593ccb55b
prerequisite-patch-id: 346f4bad40a14c72fe5966a9adb0d258592bb546
prerequisite-patch-id: aa59ee029b6f5b24d6870208ebe8a5464204cad1
prerequisite-patch-id: 2830113c25f6fafe3857fbd4685efb161d19984d
Best regards,
--
With best wishes
Dmitry