All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 00/14] drm/msm: fix the error handling of the KMS init
@ 2026-10-23 15:31 Dmitry Baryshkov
  2026-10-23 15:31 ` [PATCH v2 01/14] drm/msm: fail the snapshot init when its worker cannot be created Dmitry Baryshkov
                   ` (13 more replies)
  0 siblings, 14 replies; 16+ messages in thread
From: Dmitry Baryshkov @ 2026-10-23 15:31 UTC (permalink / raw)
  To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
	Sean Paul, Marijn Suijten, David Airlie, Simona Vetter
  Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel

When setting up the KMS fails, msm_drm_kms_init() cleans up by calling
the ->destroy() callback of the kms driver. That makes ->destroy()
responsible for tearing down a KMS in any state, from "not initialised at
all" to "fully initialised", and the drivers get it wrong in several
ways:

 - dpu_kms_hw_init() and mdp5_init() already clean up after their own
   failures, and ->destroy() then finalises the global state object a
   second time;

 - mdp4_destroy() dereferences mdp4_kms->dev, which isn't set yet when
   mdp_kms_init() fails;

 - msm_kms_init() leaves a NULL workqueue behind when it fails to
   allocate it, which msm_kms_destroy() passes to destroy_workqueue();

 - msm_drm_kms_init() hands a half initialised KMS to the full teardown
   of msm_drm_kms_uninit(), and the snapshot init ignores the failure to
   create its worker;

 - the IOMMU fault handler and the DPU interrupts can queue a display
   snapshot on its worker after it has been destroyed, or against a KMS
   which is still being set up;

 - the MDP5 driver appends its hardware blocks to the arrays in
   mdp5_kms on every bind and overflows them on the next bind;

 - the DPU never cleans up its self-refresh helpers, whose delayed work
   then commits to a KMS which has been torn down.

Most of these were pointed out by Sashiko while reviewing the "drm/msm:
fix SMMU fault dumps" series, which has been carrying the first fixes.
Rather than teaching ->destroy() about ever more partial states, this
series switches the KMS init to the usual kernel convention: every init
function undoes its own steps when it fails, and ->destroy() only ever
tears down a KMS which was initialised successfully. This reverses the
approach of commit 93c125e4ea98 ("drm/msm: don't tear down KMS twice when
KMS init fails"), which moved all of the cleanup into ->destroy().

To keep every step safe and bisectable, the drivers are converted one at
a time: a temporary flag tells msm_drm_kms_init() that a driver cleans up
its own failures, and both the flag and ->hw_init(), which gets folded
into the drivers' kms_init(), are removed once all the drivers have been
converted. The last patches fix the teardown of the DPU self-refresh
helpers and follow up on the new rules: they unwind the DPU hardware
setup step by step, disable the MDP4 vdd regulator on teardown, and drop
the runtime PM flags which ->destroy() no longer needs.

Tested on DB820c (MSM8996) with both the MDP5 and the DPU drivers, with
failures injected into the msm_kms_init(), the MDP5 kms_init(), the DPU
hardware setup and after a successful kms_init(): each of them now fails
the bind cleanly, without warnings, and a later bind attempt succeeds.
Unbinding and rebinding the driver works as well, except that with MDP5
the HDMI output does not come back after a rebind (its extp clock fails
to enable), which is not affected by this series. MDP4 is build-tested
only.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v2:
- Added patches which register the KMS fault handler late, reset the
  MDP5 hardware block counts and clean up the DPU self-refresh helpers
- The unwind of dpu_kms_hw_init() now clears the drmm-allocated hw block
  pointers, dpu_kms outlives them into the next bind (Sashiko)
- kms->vm, kms->wq and the timer workers are cleared on teardown too
- Moved the MDP5 counts fix to the front, merged the error exits of
  msm_drm_init(), clarified the fault handler and self-refresh commit
  messages
- Link to v1: https://patch.msgid.link/20261003-msm-kms-destroy-fixes-v1-0-e062b7dae77f@oss.qualcomm.com

---
Dmitry Baryshkov (14):
      drm/msm: fail the snapshot init when its worker cannot be created
      drm/msm/mdp5: forget the hardware blocks of a previous bind
      drm/msm: unwind msm_drm_kms_init() on failure
      drm/msm: order the display snapshot sources around its worker
      drm/msm: clean up after a failed msm_kms_init()
      drm/msm: let the kms drivers clean up a failed kms_init()
      drm/msm/mdp5: unwind a failed mdp5_kms_init()
      drm/msm/mdp4: unwind a failed mdp4_kms_init()
      drm/msm/dpu: don't tear down a failed hw_init twice
      drm/msm: tear down only a successfully initialised KMS
      drm/msm/dpu: clean up the self-refresh helpers on teardown
      drm/msm/dpu: unwind a failed dpu_kms_hw_init() step by step
      drm/msm/mdp4: disable the vdd regulator on teardown
      drm/msm: drop the runtime PM flags from the KMS teardown

 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c      | 73 ++++++++++++++++------------
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h      |  1 -
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c     | 68 ++++++++++++++++----------
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.h     |  2 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c     | 52 ++++++++++++--------
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h     |  2 -
 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 12 ++++-
 drivers/gpu/drm/msm/msm_atomic.c             |  1 +
 drivers/gpu/drm/msm/msm_drv.c                | 29 +++++++----
 drivers/gpu/drm/msm/msm_kms.c                | 55 +++++++++++----------
 drivers/gpu/drm/msm/msm_kms.h                | 19 +++++---
 11 files changed, 190 insertions(+), 124 deletions(-)
---
base-commit: 5e4a3f7b262060d70cfdc7889cfe0f4aba9ea3fc
change-id: 20260930-msm-kms-destroy-fixes-0f04b1d39b83

Best regards,
--  
With best wishes
Dmitry


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2026-10-23 16:00 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-23 15:31 [PATCH v2 00/14] drm/msm: fix the error handling of the KMS init Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 01/14] drm/msm: fail the snapshot init when its worker cannot be created Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 02/14] drm/msm/mdp5: forget the hardware blocks of a previous bind Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 03/14] drm/msm: unwind msm_drm_kms_init() on failure Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 04/14] drm/msm: order the display snapshot sources around its worker Dmitry Baryshkov
2026-10-23 16:00   ` sashiko-bot
2026-10-23 15:31 ` [PATCH v2 05/14] drm/msm: clean up after a failed msm_kms_init() Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 06/14] drm/msm: let the kms drivers clean up a failed kms_init() Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 07/14] drm/msm/mdp5: unwind a failed mdp5_kms_init() Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 08/14] drm/msm/mdp4: unwind a failed mdp4_kms_init() Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 09/14] drm/msm/dpu: don't tear down a failed hw_init twice Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 10/14] drm/msm: tear down only a successfully initialised KMS Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 11/14] drm/msm/dpu: clean up the self-refresh helpers on teardown Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 12/14] drm/msm/dpu: unwind a failed dpu_kms_hw_init() step by step Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 13/14] drm/msm/mdp4: disable the vdd regulator on teardown Dmitry Baryshkov
2026-10-23 15:31 ` [PATCH v2 14/14] drm/msm: drop the runtime PM flags from the KMS teardown Dmitry Baryshkov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.