[Intel-gfx] [PATCH 1/2] drm/edid: Add a EDID edp panel quirk for forcing max lane count

[Ville Syrjälä]

On Wed, Apr 03, 2019 at 12:07:35PM -0700, Manasi Navare wrote:
> On Wed, Apr 03, 2019 at 09:55:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
> > > On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
> > > > > For certain eDP 1.4 panels, we need to use max lane count for the
> > > > > link training to succeed.
> > > > > 
> > > > > This patch adds a EDID quirk for such eDP panels using
> > > > > their vendor ID and product ID to force using max lane count in the driver.
> > > > 
> > > > Rather than opening the quirk can of worms I think we should consider
> > > > changing the retry loop to do something more sensible than what it's
> > > > doing now. The current behaviour of "start at optimal settings (which
> > > > can be either min lanes or min rate), and then reduce lanes/rate until
> > > > stuff works" overlooks several possible combinations. One possible
> > > > approach could be to start the retry loop with max lanes + max rate
> > > > after the optimal settings have failed. It probably won't give you
> > > > the best power consumption, but at least you get a picture on the
> > > > screen if even a single lane count + rate combo works.
> > > >
> > > 
> > > So you are saying that for eDP only we should modify the retry function to
> > > retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
> > > 
> > > Hmm I could try doing that, the only concern I have there is that certain eDP
> > > panels just need a retry at same parameters to work so for such panels
> > > where the lower values of link rate/lane count work with just an extra retry
> > > we would still be using max link rate /lane count now with this change.
> > 
> > If the panels are borked then I wouln't worry about it as long a picture
> > appaears on the screen. And if the extra training cycle is because of
> > some bug in our code then we should figure it out what that bug is.
> >
> 
> But we should do this retrain() in our existing modeset_retry() and intel_dp_get_fallback_values()
> and only do it for eDP right?
> Because DP we have the retrain loops as per the compliance, if we change that that will
> affect all the compliance tests.

I have a rather low opinion on the compliance tests. If they are
preventing sensible real world things then what good are they?
Someone should probably figure out what it would take to make
them more useful...

But anyways, I guess we can start with eDP. If it looks like
DP could benefit as well we might have to consider it.

-- 
Ville Syrjälä
Intel