From: Johan Hovold <johan@kernel.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
Rob Clark <robdclark@gmail.com>,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Kuogee Hsieh <quic_khsieh@quicinc.com>
Cc: Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Bjorn Andersson <quic_bjorande@quicinc.com>,
quic_jesszhan@quicinc.com, quic_sbillaka@quicinc.com,
dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
linux-arm-msm@vger.kernel.org, regressions@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: drm/msm: Second DisplayPort regression in 6.8-rc1
Date: Mon, 19 Feb 2024 14:38:41 +0100 [thread overview]
Message-ID: <ZdNZ4TiJn9-yKT5_@hovoldconsulting.com> (raw)
In-Reply-To: <ZdMwZa98L23mu3u6@hovoldconsulting.com>
On Mon, Feb 19, 2024 at 11:41:41AM +0100, Johan Hovold wrote:
> It seems my initial suspicion that at least some of these regressions
> were related to the runtime PM work was correct. The hard resets happens
> when the DP controller is runtime suspended after being probed:
> [ 17.074925] bus: 'platform': __driver_probe_device: matched device aea0000.displayport-controller with driver msm-dp-display
> [ 17.112000] msm-dp-display aea0000.displayport-controller: dp_display_probe - populate aux bus
> [ 17.125208] msm-dp-display aea0000.displayport-controller: dp_pm_runtime_resume
> [ 17.197909] msm-dp-display aea0000.displayport-controller: dp_pm_runtime_suspend
> [ 17.198079] probe of aea0Format: Log Type - Time(microsec) - Message - Optional Info
> Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
> S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1
> S - IMAGE_VARIANT_STRING=SocMakenaWP
> S - OEM_IMAGE_VERSION_STRING=crm-ubuntu92
>
> < machine is reset by hypervisor >
>
> Presumably the reset happens when controller is being shut down while
> still being used by the EFI framebuffer.
>
> In the cases where the machines survives boot, the controller is never
> suspended.
>
> When investigating this I've also seen intermittent:
>
> [drm:dp_display_probe [msm]] *ERROR* device tree parsing failed
Note that there are further indications there may be more than one bug
here too.
I definitely see hard resets when dp_pm_runtime_suspend() is shutting
down the eDP PHY, but there are occasional resets also if I instrument
DP controller probe() to resume and then prevent the controller from
suspending until after a timeout (e.g. to be used as a temporary
workaround):
[ 15.676495] bus: 'platform': __driver_probe_device: matched device aea0000.displayport-controller with driver msm-dp-display
[ 15.769392] msm-dp-display aea0000.displayport-controller: dp_display_probe - populate aux bus
[ 15.778808] msm-dp-display aea0000.displayport-controller: dp_display_probe - scheduling handover
[ 15.789931] probe of aea0000.displayport-controller returned 0 after 91121 usecs
[ 15.790460] bus: 'dp-aux': __driver_probe_device: matched device aux-aea0000.displayport-controller with driver panel-simple-dp-aux
Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.MXF.1.1-00470-MAKENA-1
I'll wait for the maintainers and authors of this code to comment, but
it seems the runtime PM work is broken in multiple ways.
Johan
next prev parent reply other threads:[~2024-02-19 13:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-13 11:42 drm/msm: DisplayPort regressions " Johan Hovold
2024-02-13 18:00 ` Abhinav Kumar
2024-02-14 13:18 ` Linux regression tracking (Thorsten Leemhuis)
2024-02-14 13:52 ` Johan Hovold
2024-02-17 15:14 ` Johan Hovold
2024-02-19 10:41 ` drm/msm: Second DisplayPort regression " Johan Hovold
2024-02-19 13:38 ` Johan Hovold [this message]
2024-02-20 21:19 ` Abhinav Kumar
2024-02-21 8:05 ` Johan Hovold
2024-02-17 15:22 ` drm/msm: DisplayPort regressions " Johan Hovold
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=ZdNZ4TiJn9-yKT5_@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_bjorande@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=quic_khsieh@quicinc.com \
--cc=quic_sbillaka@quicinc.com \
--cc=regressions@lists.linux.dev \
--cc=robdclark@gmail.com \
--cc=sean@poorly.run \
/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
Powered by JetHome