[Intel-gfx] [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Imre Deak]

On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
> On Mon, 22 Jan 2018, Imre Deak <imre.deak at intel.com> wrote:
> > On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> >> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> >> > In case of eDP because the panel has a fixed mode, the link rate
> >> > and lane count at which it is trained corresponds to the link BW
> >> > required to support the native resolution of the panel. In case of
> >> > panles with lower resolutions where fewer lanes are hooked up internally,
> >> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> >> > So it is pointless to fallback to lower link rate/lane count in case
> >> > of link training failure on eDP connector since the lower link BW
> >> > will not support the native resolution of the panel and we cannot
> >> > prune the preferred mode on the eDP connector.
> >> > 
> >> > In case of Link training failure on the eDP panel, something is wrong
> >> > in the HW internally and hence driver errors out with a loud
> >> > and clear DRM_ERROR message.
> >> > 
> >> > v2:
> >> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> >> > 
> >> > Cc: Clinton Taylor <clinton.a.taylor at intel.com>
> >> > Cc: Jim Bride <jim.bride at linux.intel.com>
> >> > Cc: Jani Nikula <jani.nikula at linux.intel.com>
> >> > Cc: Ville Syrjala <ville.syrjala at linux.intel.com>
> >> > Cc: Dave Airlie <airlied at redhat.com>
> >> > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> >> > Signed-off-by: Manasi Navare <manasi.d.navare at intel.com>
> >> > Reviewed-by: Ville Syrjala <ville.syrjala at linux.intel.com>
> >> 
> >> This fell through the cracks, looks like it partially fixes
> >> https://bugs.freedesktop.org/show_bug.cgi?id=103369
> >> 
> >> Why link training fails there is not clear.
> >
> > Ok, the link training fail turned out to be a race between a modeset
> > link training and a link retraining called from
> > runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
> > one was fixed meanwhile by
> >
> > commit 42e5e65765265485ecf2a480c244d76c2c624449
> > Author:     Daniel Vetter <daniel.vetter at ffwll.ch>
> > AuthorDate: Mon Nov 13 17:01:40 2017 +0100
> > Commit:     Daniel Vetter <daniel.vetter at ffwll.ch>
> > CommitDate: Thu Nov 23 14:59:07 2017 +0100
> >
> >     drm/i915: sync dp link status checks against atomic commmits
> >
> > I merged now this fix to address the other issue, adding the above bug
> > as reference. Thanks for the patch and the review.
> 
> Thanks for the follow-up... but should we have added a Fixes: or cc:
> stable tag here?

Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
training failure")

I wasn't sure about stable, since for me the link training failure
happened only due to the bug fixed by 42e5e65765265. In any case I can't
see how it could cause problems, so yes let's Cc: stable too.

--Imre