On Mon, Dec 14, 2015 at 06:30:28PM +0200, Ville Syrjälä wrote: > On Mon, Dec 14, 2015 at 04:23:41PM +0100, Thierry Reding wrote: > > 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@xxxxxxxxxx> > > > > > > > > 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. > > Would be nice to have some *actual* numbers in the commit message, > otherwise it's all just guesswork. I only have a limited range of test equipment. In the primary test-case, which is an eDP panel, the difference was ~4.5 ms for udelay()/mdelay() and ~5 ms for the usleep_range() case. I'll see if I can get one more test setup running for better comparison. Thierry
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
