Re: [PATCH] drm/dp: Do not busy-loop during link training

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1347 bytes --]

On Mon, Dec 14, 2015 at 04:48:09PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 02:21:56PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Use microsecond sleeps for the clock recovery and channel equalization
> > delays during link training. The duration of these delays can be from
> > 100 us up to 16 ms. It is rude to busy-loop for that amount of time.
> 
> Do you have some numbers on how this affects a typical link training
> cycle?

Not really. Sinks aren't required to provide a value here, in which case
the specification says that a default of 100 us and 400 us should be
used for clock recovery and channel equalization, respectively. If the
sink provides an AUX_RD_INTERVAL value, it is used for both CR and CE
(and is in units of 4 ms). Best case a typical link training cycle would
therefore take something like 0.5 ms and worst case, since the number of
retries should be limited to 5, it'd be around 5 * 16 ms = 80 ms. That's
not counting the actual AUX transactions, though they should be pretty
fast.

Since this patch uses usleep_range(min, min * 2) the worst case now
becomes ~ 160 ms. That's still not very much from a responsiveness point
of view, but the upside is of course that there are no busy loops that
could potentially hog the CPU.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel