[PATCHv3 2/3] drm/i915/dp: read Aux RD interval just before setting the FFE preset

[Murthy, Arun R]

> -----Original Message-----
> From: Jani Nikula <jani.nikula at linux.intel.com>
> Sent: Wednesday, September 25, 2024 2:18 PM
> To: Murthy, Arun R <arun.r.murthy at intel.com>; intel-xe at lists.freedesktop.org;
> intel-gfx at lists.freedesktop.org
> Cc: Murthy, Arun R <arun.r.murthy at intel.com>; Srikanth V, NagaVenkata
> <nagavenkata.srikanth.v at intel.com>; Kandpal, Suraj
> <suraj.kandpal at intel.com>
> Subject: Re: [PATCHv3 2/3] drm/i915/dp: read Aux RD interval just before
> setting the FFE preset
> 
> On Wed, 25 Sep 2024, Arun R Murthy <arun.r.murthy at intel.com> wrote:
> > Figure 3-52: 128b132b DP DPTC LANEx_CHANNEL_EQ_DONE Sequence of
> DP2.1a
> > spec.
> > After reading LANEx_CHANNEL_EQ_DONE, read the FFE presets.
> > AUX_RD_INTERVAL and then write the new FFE presets.
> 
> Nope. That's just not what the figure has.
> 
> > Co-developed-by: Srikanth V NagaVenkata
> > <nagavenkata.srikanth.v at intel.com>
> > Signed-off-by: Arun R Murthy <arun.r.murthy at intel.com>
> > Reviewed-by: Suraj Kandpal <suraj.kandpal at intel.com>
> > ---
> >  .../gpu/drm/i915/display/intel_dp_link_training.c  | 14
> > +++++++-------
> >  1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index f41b69840ad9..1bac00e46533 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -1419,12 +1419,6 @@ intel_dp_128b132b_lane_eq(struct intel_dp
> *intel_dp,
> >  	for (try = 0; try < max_tries; try++) {
> >  		fsleep(delay_us);
> >
> > -		/*
> > -		 * The delay may get updated. The transmitter shall read the
> > -		 * delay before link status during link training.
> > -		 */
> > -		delay_us =
> drm_dp_128b132b_read_aux_rd_interval(&intel_dp->aux);
> > -
> >  		if (drm_dp_dpcd_read_link_status(&intel_dp->aux, link_status)
> < 0) {
> >  			lt_err(intel_dp, DP_PHY_DPRX, "Failed to read link
> status\n");
> >  			return false;
> > @@ -1451,8 +1445,14 @@ intel_dp_128b132b_lane_eq(struct intel_dp
> *intel_dp,
> >  		if (time_after(jiffies, deadline))
> >  			timeout = true; /* try one last time after deadline */
> >
> > -		/* Update signal levels and training set as requested. */
> >  		intel_dp_get_adjust_train(intel_dp, crtc_state, DP_PHY_DPRX,
> > link_status);
> > +		/*
> > +		 * During LT, Tx shall read AUX_RD_INTERVAL just before
> writing the new FFE
> > +		 * presets.
> > +		 */
> > +		delay_us =
> drm_dp_128b132b_read_aux_rd_interval(&intel_dp->aux);
> 
> I said this should be put *above* intel_dp_get_adjust_train(), and you agreed.
> There was even a patch to that effect, and that's what I thought we were going
> by.
> 
Yes I had pushed a patch also, but later based on Suraj comment pointing to the spec changed this. I am not able to find that again in spec.

> It's both logical and per spec to keep the TX FFE PRESET read and write
> together, and AUX RD INTERVAL read *before* them.
> 
Yes agree!

> Where does the spec say, "read AUX_RD_INTERVAL just before writing the new
> FFE presets"? I don't think it does.
> 
> The box in figure 3-52 has:
> 
> - Read AUX_RD_INTERVAL value
> 
> - Adjust the TX_FFE_PRESET_VALUE setting as requested by a
>   DPRX/LTTPR_UFP
> 
> The "as requested by" part involves reading TX FFE PRESET to know what the
> DPRX requested.
> 
Yes, but I now see a different thing now
" During LT, the transmitter shall read DPCD 02216h before DPCD 00202h through 00207h,
and 0200Ch through 0200Fh. If DPCD 00204h[0] = 0 and DPCD 0200Eh[0] = 0, the transmitter
shall adjust the drive setting according to the receiver's request, and then write the new setting
to DPCD 00103h through 00106h and re-initiate the receiver counter"

Ref: 3.5.2.16.1.1 of spec DP2.1

Here it says read AUX_RD_INTERVAL before reading the lane states(0x0202, 0x0203) reading the
FFE presets(0x0206, 0x0207), which is what our original code was doing.

> I don't see anything wrong in the original comment, just the placement of the
> read.
> 
> There have been a multitude of different patches with random version numbers
> with no changelog and I don't even know what I'm supposed to be reviewing
> anymore.
> 
Sorry for that!

Thanks and Regards,
Arun R Murthy
--------------------