From: joonhoekim <26rote@gmail.com>
To: Xilin Wu <sophon@radxa.com>
Cc: Joonhoe Kim <26rote@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
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>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Kevin Hilman <khilman@baylibre.com>,
Jerome Brunet <jbrunet@baylibre.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org,
dragon@radxa.com, linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 09/20] drm/msm/dp: Unwind resources when enabling a stream fails
Date: Tue, 3 Nov 2026 22:51:40 +0900 [thread overview]
Message-ID: <20261103135141.1993-1-26rote@gmail.com> (raw)
In-Reply-To: <20261009-msm-dp-hdr10-v2-9-1835d4966da3@radxa.com>
From: Joonhoe Kim <26rote@gmail.com>
On Fri, 09 Oct 2026 11:16:01 +0800, Xilin Wu wrote:
> Stream enable can fail after acquiring a runtime PM reference or
> starting the link. Returning directly leaks those resources, while a
> later disable can release a reference that was never acquired.
This leak breaks USB on a Lenovo Y700 Gen 5 (TB323FU, Kaanapali). I
tried parts of 08/20 and this patch as a fix for it. The result was
worse.
The sequence, seen with kprobes on v7.3 with out-of-tree board
support:
- A USB-C monitor is unplugged during s2idle. On resume, the stream
enable trains the link to the gone sink and fails. Nothing releases
the DP PHY init taken for it.
- At the next suspend entry (booted with no_console_suspend, so fbcon
restores the old mode), an enable on the disconnected connector
powers the DP PHY on, and msm_dp_ctrl_enable_mainlink_clocks() fails
with -EBUSY. The PHY power is not released either.
- The DP side now holds the QMP combo PHY. On the next resume,
qmp_combo_usb_init() skips the common block init, and
qmp_combo_usb_power_on() times out waiting for PHYSTATUS. The dwc3
resume fails with -110, and USB stays down until reboot.
On top of v7.3 I applied only the PHY power tracking from 08/20, the
power-off on the link clock failure from this patch, and a backport of
1bda647ce61b ("drm/msm/dp: move link-level teardown from
display_disable to display_unprepare") from msm-next. Then the same
unplug during s2idle crashed the SoC:
[drm:msm_dp_ctrl_link_train_1_2] *ERROR* link training #1 on phy 0 failed. ret=-110
...
[drm:msm_dp_display_atomic_enable] *ERROR* DP display prepare failed, rc=-104
[drm:dpu_encoder_phys_vid_wait_for_commit_done:583] [dpu error]vblank timeout: a0820302
[drm:dpu_encoder_phys_vid_disable] *ERROR* wait disable failed: id:37 intf:0 ret:-110
The device then reset into its crash dump mode. It crashed the same way
once more, after a failed link training during repeated VT switches
with the monitor attached. There the log went on 10 ms later with:
qcom_q6v5_pas d00000.remoteproc: fatal error received: sys_m_smsm.c:503:TZ force stop
Without these changes I saw the same failed enable and "wait disable
failed" three times, with no crash.
My guess is that the DP PHY, which clocks the DPU video interface, is
now turned off while that interface is still enabled. I have not
confirmed it. So I can't give a Tested-by. The PHY leak is still open
here.
Thanks,
Joonhoe Kim
next prev parent reply other threads:[~2026-11-03 13:51 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 3:15 [PATCH v2 00/20] drm/msm/dp: Add static HDR support for DP and eDP Xilin Wu
2026-10-09 3:15 ` [PATCH v2 01/20] drm/atomic: Handle max bpc properties before connector state allocation Xilin Wu
2026-10-10 2:48 ` Chaoyi Chen
2026-10-12 12:33 ` Dmitry Baryshkov
2026-10-09 3:15 ` [PATCH v2 02/20] drm/connector: Drop early state allocation for max bpc registration Xilin Wu
2026-10-10 22:44 ` Martin Blumenstingl
2026-10-09 3:15 ` [PATCH v2 03/20] drm/bridge-connector: Attach max bpc for non-HDMI bridges Xilin Wu
2026-10-10 2:39 ` Chaoyi Chen
2026-10-12 12:40 ` Dmitry Baryshkov
2026-10-09 3:15 ` [PATCH v2 04/20] drm/msm/dp: Accept a const SDP header when packing Xilin Wu
2026-10-09 3:15 ` [PATCH v2 05/20] drm/msm/dp: Support multiple generic SDP slots Xilin Wu
2026-10-09 3:15 ` [PATCH v2 06/20] drm/msm/dp: Keep runtime PM calls outside the connection lock Xilin Wu
2026-10-09 3:15 ` [PATCH v2 07/20] drm/msm/dp: Serialize stream operations with HPD processing Xilin Wu
2026-10-12 12:48 ` Dmitry Baryshkov
2026-10-09 3:16 ` [PATCH v2 08/20] drm/msm/dp: Track PHY power ownership Xilin Wu
2026-10-09 3:16 ` [PATCH v2 09/20] drm/msm/dp: Unwind resources when enabling a stream fails Xilin Wu
2026-11-03 13:51 ` joonhoekim [this message]
2026-10-09 3:16 ` [PATCH v2 10/20] drm/msm/dp: Report stream enable failures through link status Xilin Wu
2026-10-09 3:16 ` [PATCH v2 11/20] drm/msm/dp: Cache eDP link capabilities after successful discovery Xilin Wu
2026-10-30 4:29 ` Burke Cates
2026-10-09 3:16 ` [PATCH v2 12/20] drm/msm/dp: Rebuild the eDP stream on modesets leaving self refresh Xilin Wu
2026-10-09 3:16 ` [PATCH v2 13/20] drm/msm/dp: Track output bit depth in bridge atomic state Xilin Wu
2026-10-09 3:16 ` [PATCH v2 14/20] drm/msm/dp: Clear stale MSA colorimetry bits Xilin Wu
2026-10-12 8:00 ` Konrad Dybcio
2026-10-09 3:16 ` [PATCH v2 15/20] drm/msm/dp: Flush VSC updates when leaving YUV420 Xilin Wu
2026-10-12 14:09 ` Dmitry Baryshkov
2026-10-09 3:16 ` [PATCH v2 16/20] drm/msm/dp: Disable PSR for YUV420 streams Xilin Wu
2026-10-12 14:36 ` Dmitry Baryshkov
2026-10-09 3:16 ` [PATCH v2 17/20] drm/msm/dp: Track VSC packets in bridge atomic state Xilin Wu
2026-10-09 3:16 ` [PATCH v2 18/20] drm/msm/dp: Signal BT.2020 RGB on DP and eDP Xilin Wu
2026-10-12 14:48 ` Dmitry Baryshkov
2026-10-09 3:16 ` [PATCH v2 19/20] drm/msm/dp: Serialize video test state changes Xilin Wu
2026-10-12 21:52 ` Dmitry Baryshkov
2026-10-09 3:16 ` [PATCH v2 20/20] drm/msm/dp: Add static HDR metadata support for DP and eDP Xilin Wu
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=20261103135141.1993-1-26rote@gmail.com \
--to=26rote@gmail.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=dragon@radxa.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=jesszhan0024@gmail.com \
--cc=jonas@kwiboo.se \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=sophon@radxa.com \
--cc=tzimmermann@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®