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

[Murthy, Arun R]

> -----Original Message-----
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Sent: Monday, July 4, 2022 7:41 PM
> To: Murthy, Arun R <arun.r.murthy at intel.com>
> Cc: intel-gfx at lists.freedesktop.org; Zanoni, Paulo R
> <paulo.r.zanoni at intel.com>; tprevite at gmail.com; Shankar, Uma
> <uma.shankar at intel.com>; Nikula, Jani <jani.nikula at intel.com>
> Subject: Re: [PATCH] drm/i915/dp: wait on timeout before retry
> 
> On Mon, Jul 04, 2022 at 12:53:52PM +0530, Arun R Murthy wrote:
> > On linktraining error/timeout before retry need to wait for 400usec as
> > per the DP CTS spec1.2
> 
> s/CTS//
> 
> > Under section 2.7.2 AUX Transaction Response/Reply Time-outs AUX
> > Replier (the uPacket RX) must start sending the reply back to the AUX
> > requester (the uPacket TX) within the response period of 300μs. The
> > timer for Response Time-out starts ticking after the uPacket RX has
> > finished receiving the AUX STOP condition which ends the AUX Request
> transaction.
> > The timer is reset either when the Response Time-out period has
> > elapsed or when the uPacket RX has started to send the AUX Sync
> > pattern (which follows
> > 10 to 16 active pre-charge pulses) for the Reply transaction. If the
> > uPacket TX does not receive a reply from the uPacket RX it must wait
> > for a Reply Time-out period of 400us before initiating the next AUX
> > Request transaction. The timer for the Reply Time-out starts ticking
> > after the uPacket TX has finished sending the AUX STOP condition.
> >
> > 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.
> 
> Not sure what you're saying here. The spec states the reply timeout should
> start counting once the TX has sent the AUX STOP, and gets reset when the
> reply AUX SYNC is detected.
> 
> If that doesn't match what the hardware is doing then we really need to get
> bspec updated to say what is actually happening.
> 
> Oh, and the reply timeout has been increased to 3.2ms in later revisions of
> the spec to deal with LTTPRs. We should adjust the code to match.
> 
Will take this separately!

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