Re: [PATCH] drm/i915: DP link training optimization

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

On Thu, Feb 26, 2015 at 06:29:45PM -0700, Todd Previte wrote:
> Hi Mika,
> 
> On 2/26/2015 2:26 AM, Mika Kahola wrote:
> > In a case when DP link has been once trained we can reuse
> > the existing link training parameters i.e. voltage swing
> > and pre-emphasis levels from cache when there is a need to
> > restart link training. In a case of eDP we initially try
> > to train the link by using the parameter set that we can find
> > from VBT. The fallback on both cases is to reset the link
> > training parameters and restart.
> I think you have a good idea here for the eDP case. But the way it's 
> coded, there appear to be cases where the code will try to reuse the 
> same training settings for regular DP as well. That will likely have 
> some unfortunate results, as there's no guarantee for a normal external 
> Displayport connection that training settings which worked once will 
> work the next time. This would be of particular concern when 
> disconnecting and reconnecting Displayport sink devices, as it appears 
> as though it would try to retrain the newly connected device using the 
> previously valid settings for the old device.
> 
> IMHO, this really needs to be written as eDP only and such that it can 
> never occur on an external Displayport device. Otherwise, it seems like 
> there's a good chance of ending up with a black screen when you plug in 
> a Displayport monitor.

I've thought we should retrain with the same parameters we used the
last time iff the link was succesully trained using those parameters
in the past and the sink hasn't been disconnected in the meantime.
We'd do this in the hopes of speeding up subsequent link trainings.
So resetting the saved parameters on link training failure and long
HPD should be good enough here, I think.

And this way the VBT thing could just be a special case where we just
sort of pretend that we succesfully trained the link using those
parameters in the past. Oh and we could also read out the state from
the hardware during init, and assuming the link was up and stable at
the time we could populate the "previous good values" from whatever
the BIOS actually programmed into the hardware.

Anyway, that's just how I've imagined we should implement this kind of
stuff.

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