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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Mon, Jan 11, 2016 at 09:36:04AM +0100, Thierry Reding wrote:
> 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@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.
> > 
> > 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.

Hmm. Depending on how many iterations it took 5ms could be quite a bit,
or not much at all. I think ideally link training shouldn't take very
many milliseconds if you don't have iterate the settings too much. I've
not measured this myself in a while though, and I'm sure we're much
worse at least on some platforms currently.

But at least a few sample numbers in the commit message could then help
people if they later have to look into why link training is taking as
long as it is.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel