[Intel-gfx] [PATCHv3] drm/i915/dp: wait on timeout before retry

[Murthy, Arun R]

> > -----Original Message-----
> > From: Nikula, Jani <jani.nikula at intel.com>
> > Sent: Friday, July 1, 2022 4:45 PM
> > To: Murthy, Arun R <arun.r.murthy at intel.com>;
> > intel-gfx at lists.freedesktop.org
> > Cc: ville.syrjala at linux.intel.com; Zanoni, Paulo R
> > <paulo.r.zanoni at intel.com>; tprevite at gmail.com; Shankar, Uma
> > <uma.shankar at intel.com>; Murthy, Arun R <arun.r.murthy at intel.com>
> > Subject: Re: [PATCHv3] drm/i915/dp: wait on timeout before retry
> >
> > On Fri, 01 Jul 2022, Arun R Murthy <arun.r.murthy at intel.com> wrote:
> > > On linktraining error/timeout before retry need to wait for 400usec
> > > as per the DP CTS spec1.2
> > >
> > > The patch with commit 74ebf294a1dd ("drm/i915: Add a delay in
> > > Displayport AUX transactions for compliance testing") removes this
> > > delay mentioning the hardware already meets this requirement, but as
> > > per the spec the delay mentioned in the spec specifies how long to
> > > wait for the receiver response before timeout. So the delay here to
> > > wait for timeout and not a delay after timeout. The DP spec
> > > specifies a delay after timeout and hence adding this delay.
> 
> The source side as per bspec says how much time to wait for sink response
> before calling timeout:
> Reg: DDI_AUX_CTL, BitField: 27:26
> Name: Time out timer value
> Description:
> ValueName
> 00b400us (default)
> 01b600us
> 10b800us
> 11b4000us
> 
> So this should meet the CTS requirement. For any non-timeout error from
> sink, s/w should add explicit delay of minimum 400us before retry (which is
> being done)
> 
> If 400us is not enough this needs to be checked separately or the timeout
> value in this register can be changed from default of 400us
> 
The delay specified in the register is the time to wait for triggering the timeout. This is being achieved in the register mentioned above.

But what the CTS spec says is once the timeout has occurred, before retrying again we need to wait for 400ms. This is the delay that this patch has added.

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