All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Rob Clark <robin.clark@oss.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Jessica Zhang <jesszhan0024@gmail.com>,
	Sean Paul <sean@poorly.run>,
	Marijn Suijten <marijn.suijten@somainline.org>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>
Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 12/14] drm/msm/dpu: unwind a failed dpu_kms_hw_init() step by step
Date: Mon, 26 Oct 2026 10:44:05 +0100	[thread overview]
Message-ID: <fa95ecee-e6e3-46da-abc3-a9e0e6be24dc@oss.qualcomm.com> (raw)
In-Reply-To: <20261024-msm-kms-destroy-fixes-v3-12-66a30120a5ea@oss.qualcomm.com>

On 10/24/26 1:19 AM, Dmitry Baryshkov wrote:
> When dpu_kms_hw_init() fails it calls _dpu_kms_hw_destroy(), the teardown
> of a fully initialised KMS, whatever step it failed at.
> 
> Undo only the steps which have completed, in the reverse order, as the
> kernel convention wants.
> 
> The hw_mdp, hw_vbif and hw_intr blocks are allocated with drmm and go
> away with the DRM device, while dpu_kms stays around for the next bind
> attempt, so clear the pointers to them as _dpu_kms_hw_destroy() did.
> Otherwise dpu_runtime_resume() of the next bind attempt passes the stale
> hw_vbif to dpu_vbif_init_memtypes() before dpu_kms_hw_init() sets it.
> 
> Assisted-by: LLM
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---

LLM is slightly curious about not clearing dpu_kms->catalog but
I think it's fine

Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

  reply	other threads:[~2026-10-26  9:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-23 23:19 [PATCH v3 00/14] drm/msm: fix the error handling of the KMS init Dmitry Baryshkov
2026-10-23 23:19 ` [PATCH v3 01/14] drm/msm: fail the snapshot init when its worker cannot be created Dmitry Baryshkov
2026-10-26  9:21   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 02/14] drm/msm/mdp5: forget the hardware blocks of a previous bind Dmitry Baryshkov
2026-10-26  9:22   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 03/14] drm/msm: unwind msm_drm_kms_init() on failure Dmitry Baryshkov
2026-10-26  9:26   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 04/14] drm/msm: order the display snapshot sources around its worker Dmitry Baryshkov
2026-10-23 23:41   ` sashiko-bot
2026-10-23 23:19 ` [PATCH v3 05/14] drm/msm: clean up after a failed msm_kms_init() Dmitry Baryshkov
2026-10-26  9:30   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 06/14] drm/msm: let the kms drivers clean up a failed kms_init() Dmitry Baryshkov
2026-10-26  9:33   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 07/14] drm/msm/mdp5: unwind a failed mdp5_kms_init() Dmitry Baryshkov
2026-10-26  9:39   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 08/14] drm/msm/mdp4: unwind a failed mdp4_kms_init() Dmitry Baryshkov
2026-10-26  9:40   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 09/14] drm/msm/dpu: don't tear down a failed hw_init twice Dmitry Baryshkov
2026-10-26  9:41   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 10/14] drm/msm: tear down only a successfully initialised KMS Dmitry Baryshkov
2026-10-26  9:42   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 11/14] drm/msm/dpu: clean up the self-refresh helpers on teardown Dmitry Baryshkov
2026-10-26  9:42   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 12/14] drm/msm/dpu: unwind a failed dpu_kms_hw_init() step by step Dmitry Baryshkov
2026-10-26  9:44   ` Konrad Dybcio [this message]
2026-10-23 23:19 ` [PATCH v3 13/14] drm/msm/mdp4: disable the vdd regulator on teardown Dmitry Baryshkov
2026-10-26  9:44   ` Konrad Dybcio
2026-10-23 23:19 ` [PATCH v3 14/14] drm/msm: drop the runtime PM flags from the KMS teardown Dmitry Baryshkov
2026-10-26  9:45   ` Konrad Dybcio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa95ecee-e6e3-46da-abc3-a9e0e6be24dc@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=airlied@gmail.com \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jesszhan0024@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lumag@kernel.org \
    --cc=marijn.suijten@somainline.org \
    --cc=robin.clark@oss.qualcomm.com \
    --cc=sean@poorly.run \
    --cc=simona@ffwll.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.