[Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max

[Chris Wilson]

Quoting Jani Nikula (2018-03-09 10:20:37)
> On Thu, 08 Mar 2018, Manasi Navare <manasi.d.navare at intel.com> wrote:
> > The panels are generally designed to support only a single
> > clock and lane configuration, and typically these values
> > correspond to the native resolution of the panel. But some
> > panels advertise the MAX_LINK_RATE in DPCD higher than what
> > is required to support the native resolution.
> > So optimize and set the link rate and lane count to the
> > least values required by the panel to support the native
> > resolution. This will also be an effective power saving
> > for such eDP panels.
> 
> I'm afraid this will lead to flickering on plenty of laptops. It will
> just get reverted when it hits end users. We've been down this path
> before. If we decide to try to do this again, we need to figure out how
> *not* to regress those machines. We can't just talk our way out of this.
> 
> As a tip, it's often useful to have a look at git blame and git log when
> you're considering changes to code that seems odd or contentious or
> something. In this case that leads to commit 344c5bbcb7a2
> ("drm/i915/edp: use lane count and link rate from DPCD for eDP"), which
> in turn leads to commit 56071a207602 ("drm/i915: use lane count and link
> rate from VBT as minimums for eDP") and a bunch of bugzilla links.

Also include a bit of rationale in the comment about what happens if we
don't have that block. 

* Use the maximum clock and number of lanes the eDP panel
* advertizes being capable of. The panels are generally
* designed to support only a single clock and lane
* configuration, and typically these values correspond to the
* native resolution of the panel.

+ On some? many? panels, failure to force the maximum bandwidth results
+ in flickering, hence we unconditionally apply this w/a.
-Chris