Quoting Jani Nikula (2018-03-09 10:20:37)
> On Thu, 08 Mar 2018, Manasi Navare <manasi.d.navare@xxxxxxxxx> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
