[PATCH] drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET

[Imre Deak]

On Wed, Jul 09, 2025 at 12:55:16AM +0300, Jonathan Cavitt wrote:
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces at lists.freedesktop.org> On Behalf Of Imre Deak
> Sent: Tuesday, July 8, 2025 2:24 PM
> To: intel-gfx at lists.freedesktop.org; intel-xe at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>; Jani Nikula <jani.nikula at linux.intel.com>; Paul Menzel <pmenzel at molgen.mpg.de>
> Subject: [PATCH] drm/dp: Change AUX DPCD probe address from LANE0_1_STATUS to TRAINING_PATTERN_SET
> > 
> > Commit a40c5d727b81 ("drm/dp: Change AUX DPCD probe address from
> > DPCD_REV to LANE0_1_STATUS") stopped using the DPCD_REV register for
> > DPCD probing, since this results in link training failures at least when
> > using an Intel Barlow Ridge TBT hub at UHBR link rates (the
> > DP_INTRA_HOP_AUX_REPLY_INDICATION never getting cleared after the failed
> > link training). Since accessing DPCD_REV during link training is
> > prohibited by the DP Standard, LANE0_1_STATUS (0x202) was used instead,
> > as it falls within the Standard's valid register address range
> > (0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) and it fixed the link
> > training on the above TBT hub.
> > 
> > However, reading the LANE0_1_STATUS register also has a side-effect at
> > least on a Novatek eDP panel, as reported on the Closes: link below,
> > resulting in screen flickering on that panel. One clear side-effect when
> > doing the 1-byte probe reads from LANE0_1_STATUS during link training
> > before reading out the full 6 byte link status starting at the same
> > address is that the panel will report the link training as completed
> > with voltage swing 0. This is different from the normal, flicker-free
> > scenario when no DPCD probing is done, the panel reporting the link
> > training complete with voltage swing 2.
> > 
> > Using the TRAINING_PATTERN_SET register for DPCD probing doesn't have
> > the above side-effect, the panel will link train with voltage swing 2 as
> > expected and it will stay flicker-free. This register is also in the
> > above valid register range and is unlikely to have a side-effect as that
> > of LANE0_1_STATUS: Reading LANE0_1_STATUS is part of the link training
> > CR/EQ sequences and so it may cause a state change in the sink - even if
> > inadvertently as I suspect in the case of the above Novatek panel. As
> > opposed to this, reading TRAINING_PATTERN_SET is not part of the link
> > training sequence (it must be only written once at the beginning of the
> > CR/EQ sequences), so it's unlikely to cause any state change in the
> > sink.
> > 
> > As a side-note, this Novatek panel also lacks support for TPS3, while
> > claiming support for HBR2, which violates the DP Standard (the Standard
> > mandating TPS3 for HBR2).
> > 
> > Besides the Novatek panel (PSR 1), which this change fixes, I also
> > verified the change on a Samsung (PSR 1) and an Analogix (PSR 2) eDP
> > panel as well as on the Intel Barlow Ridge TBT hub.
> > 
> > Note that in the drm-tip tree (targeting the v6.17 kernel version) the
> > i915 and xe drivers keep DPCD probing enabled only for the panel known
> > to require this (HP ZR24w), hence those drivers in drm-tip are not
> > affected by the above problem.
> > 
> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Cc: Jani Nikula <jani.nikula at linux.intel.com>
> > Fixes: a40c5d727b81 ("drm/dp: Change AUX DPCD probe address from DPCD_REV to LANE0_1_STATUS")
> > Reported-and-tested-by: Paul Menzel <pmenzel at molgen.mpg.de>
> > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14558
> > Signed-off-by: Imre Deak <imre.deak at intel.com>
> 
> Some uses of the first person in the commit message could maybe
> be revised to speak more generally,

Since here the panel's firmware is involved, only the debugging details
provide some insight into the possible root causes and choices made for
the solution, not sure how else that process could have been described.

> but I'm not going to make that a requirement.
>
> As is, this patch is:
> Reviewed-by: Jonathan Cavitt <jonathan.cavitt at intel.com>

Thanks for the review!

> -Jonathan Cavitt
> 
> > ---
> >  drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c b/drivers/gpu/drm/display/drm_dp_helper.c
> > index 1c3920297906b..1ecc3df7e3167 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -742,7 +742,7 @@ ssize_t drm_dp_dpcd_read(struct drm_dp_aux *aux, unsigned int offset,
> >  	int ret;
> >  
> >  	if (dpcd_access_needs_probe(aux)) {
> > -		ret = drm_dp_dpcd_probe(aux, DP_LANE0_1_STATUS);
> > +		ret = drm_dp_dpcd_probe(aux, DP_TRAINING_PATTERN_SET);
> >  		if (ret < 0)
> >  			return ret;
> >  	}
> > -- 
> > 2.44.2
> > 
> >