Re: [PATCH] drm/amd/display: Restart DP stream if the sink doesn't lock onto it

[Wayne Lin <Wayne.Lin@amd.com>]

On Sat, 7 Nov 2026 at 00:24, Ambareesh Balaji wrote:
> Link training succeeding does not mean that the sink has locked onto the
> video stream that follows. Some sinks, e.g. the XREAL Air 2 Pro, are not
> ready to do so for a while after HPD. If the stream starts too early they
> stay black until the stream is restarted, even though link training
> passes and lane status is fine. They report this through DPCD
> SINK_STATUS (RECEIVE_PORT_0_STATUS stays clear). With the display
> manager starting the modeset right after HPD, this happens on most
> replugs.

Hi,
Thanks for the report!

Would like to clarify this a bit that link training success does mean the
DP sink locks the main-link symbols. RECEIVE_PORT_0_STATUS
(DPCD 00205h bit 0) stands for whether the sink regenerated a video stream
from those symbols.
Besides, when HPD is pulled high by the sink, it means the DP sink is ready
for the stream.

> After a modeset on a DP SST link, poll SINK_STATUS. If the sink doesn't
> report being in sync within a second, restart the stream the same way as
> on link loss, and keep polling. The number of restarts is limited per
> connection (reset on HPD, not on HPD RX), so a sink that never reports
> sync isn't restarted forever.

Did an IRQ_HPD occur while the panel stayed black? DP uses that HPD IRQ
instead of polling. DP 1.4 section 5.1.1.2 says a sink that cannot handle
the incoming stream toggles HPD, and the source then reads SINK_STATUS.
Polling this bit skips that handshake.

> No fixed delay is added to the normal path: sinks that lock on in time
> are never touched.
>
> Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/6101
> Signed-off-by: Ambareesh Balaji <ambareeshbalaji@gmail.com>
> ---
> Tested on Strix Halo with an XREAL Air 2 Pro, on 7.3.1 (the patch applies
> unchanged there). Without it the glasses stay black after nearly every
> replug. With it, all 30 test replugs recovered, none needed more than
> one restart.
> 
> Captures (DPCD, ftrace, HPD/USB timing) are in the issue linked above.
> In short: HPD, link training and lane/alignment status look the same on
> good and bad attempts, and nothing in DPCD changes when the glasses become
> able to lock. Only SINK_STATUS differs afterwards. Skipping detection-time
> link training (DC_SKIP_DETECTION_LT) doesn't help.
>
> Open questions:
> - Are the 1 s timeout and the limit of 4 restarts acceptable, or would you
>   prefer different values?
> - Would you rather have this as a per-sink quirk than for all DP SST sinks?

So far, it sounds more like a sink's own problem. I would intend to solve
this as a quirk now.
Curious, whether lower timing still have this issue?

> - Is there a better place to hook this, e.g. in DMUB or the HPD path?

Thanks!

Regards,
Wayne Lin