Message ID | 1400061739-28059-1-git-send-email-jani.nikula@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
We do have to continue the investigation on the link training side, but since 76711 is a critical I'm completely in favor of this workaround for now. I just tested and it worked very well here, so: Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> On Wed, May 14, 2014 at 6:02 AM, Jani Nikula <jani.nikula@intel.com> wrote: > There are certain BDW high res eDP machines that regressed due to > > commit 38aecea0ccbb909d635619cba22f1891e589b434 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Mon Mar 3 11:18:10 2014 +0100 > > drm/i915: reverse dp link param selection, prefer fast over wide again > > The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at > 2.7 Gbps on the affected machines. Link training succeeded for both, but > the screen remained blank with the former config. Further investigation > showed that 4 lanes at 5.4 Gbps worked also. > > The root cause for the blank screen using 2 lanes remains unknown, but > apparently the driver for a certain other operating system by default > uses the max available lanes. Follow suit on Broadwell eDP, for at least > until we figure out what is going on. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711 > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > --- > drivers/gpu/drm/i915/intel_dp.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index 9f67b724dc28..6eaefca0048d 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -849,7 +849,12 @@ intel_dp_compute_config(struct intel_encoder *encoder, > bpp = dev_priv->vbt.edp_bpp; > } > > - if (dev_priv->vbt.edp_lanes) { > + if (IS_BROADWELL(dev)) { > + /* Yes, it's an ugly hack. */ > + min_lane_count = max_lane_count; > + DRM_DEBUG_KMS("forcing lane count to max (%u) on > BDW\n", > + min_lane_count); > + } else if (dev_priv->vbt.edp_lanes) { > min_lane_count = min(dev_priv->vbt.edp_lanes, > max_lane_count); > DRM_DEBUG_KMS("using min %u lanes per VBT\n", > -- > 1.9.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >
On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi@gmail.com> wrote: > We do have to continue the investigation on the link training side, but > since 76711 is a critical I'm completely in favor of this workaround for > now. > > I just tested and it worked very well here, so: > > Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Pushed to -fixes, thanks for the review and testing. BR, Jani. > > > On Wed, May 14, 2014 at 6:02 AM, Jani Nikula <jani.nikula@intel.com> wrote: > >> There are certain BDW high res eDP machines that regressed due to >> >> commit 38aecea0ccbb909d635619cba22f1891e589b434 >> Author: Daniel Vetter <daniel.vetter@ffwll.ch> >> Date: Mon Mar 3 11:18:10 2014 +0100 >> >> drm/i915: reverse dp link param selection, prefer fast over wide again >> >> The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at >> 2.7 Gbps on the affected machines. Link training succeeded for both, but >> the screen remained blank with the former config. Further investigation >> showed that 4 lanes at 5.4 Gbps worked also. >> >> The root cause for the blank screen using 2 lanes remains unknown, but >> apparently the driver for a certain other operating system by default >> uses the max available lanes. Follow suit on Broadwell eDP, for at least >> until we figure out what is going on. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711 >> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >> --- >> drivers/gpu/drm/i915/intel_dp.c | 7 ++++++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> b/drivers/gpu/drm/i915/intel_dp.c >> index 9f67b724dc28..6eaefca0048d 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -849,7 +849,12 @@ intel_dp_compute_config(struct intel_encoder *encoder, >> bpp = dev_priv->vbt.edp_bpp; >> } >> >> - if (dev_priv->vbt.edp_lanes) { >> + if (IS_BROADWELL(dev)) { >> + /* Yes, it's an ugly hack. */ >> + min_lane_count = max_lane_count; >> + DRM_DEBUG_KMS("forcing lane count to max (%u) on >> BDW\n", >> + min_lane_count); >> + } else if (dev_priv->vbt.edp_lanes) { >> min_lane_count = min(dev_priv->vbt.edp_lanes, >> max_lane_count); >> DRM_DEBUG_KMS("using min %u lanes per VBT\n", >> -- >> 1.9.1 >> >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> > > > > -- > Rodrigo Vivi > Blog: http://blog.vivi.eng.br
On 15 May 2014 18:58, Jani Nikula <jani.nikula@intel.com> wrote: > On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi@gmail.com> wrote: >> We do have to continue the investigation on the link training side, but >> since 76711 is a critical I'm completely in favor of this workaround for >> now. >> >> I just tested and it worked very well here, so: >> >> Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> >> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> > > Pushed to -fixes, thanks for the review and testing. > > BR, > Jani. > >> >> >> On Wed, May 14, 2014 at 6:02 AM, Jani Nikula <jani.nikula@intel.com> wrote: >> >>> There are certain BDW high res eDP machines that regressed due to >>> >>> commit 38aecea0ccbb909d635619cba22f1891e589b434 >>> Author: Daniel Vetter <daniel.vetter@ffwll.ch> >>> Date: Mon Mar 3 11:18:10 2014 +0100 >>> >>> drm/i915: reverse dp link param selection, prefer fast over wide again >>> >>> The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at >>> 2.7 Gbps on the affected machines. Link training succeeded for both, but >>> the screen remained blank with the former config. Further investigation >>> showed that 4 lanes at 5.4 Gbps worked also. >>> >>> The root cause for the blank screen using 2 lanes remains unknown, but >>> apparently the driver for a certain other operating system by default >>> uses the max available lanes. Follow suit on Broadwell eDP, for at least >>> until we figure out what is going on. Uggh, okay this lane thing is such a pita, On haswell the Lenovo dock in SST mode is broken by the original patch as well. I'm not sure we want to do IS_HASWELL here as well, I think we need to revert 38aecea0ccbb909d635619cba22f1891e589b434 Dave.
On 14 July 2014 10:46, Dave Airlie <airlied@gmail.com> wrote: > On 15 May 2014 18:58, Jani Nikula <jani.nikula@intel.com> wrote: >> On Wed, 14 May 2014, Rodrigo Vivi <rodrigo.vivi@gmail.com> wrote: >>> We do have to continue the investigation on the link training side, but >>> since 76711 is a critical I'm completely in favor of this workaround for >>> now. >>> >>> I just tested and it worked very well here, so: >>> >>> Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> >>> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> >> >> Pushed to -fixes, thanks for the review and testing. >> >> BR, >> Jani. >> >>> >>> >>> On Wed, May 14, 2014 at 6:02 AM, Jani Nikula <jani.nikula@intel.com> wrote: >>> >>>> There are certain BDW high res eDP machines that regressed due to >>>> >>>> commit 38aecea0ccbb909d635619cba22f1891e589b434 >>>> Author: Daniel Vetter <daniel.vetter@ffwll.ch> >>>> Date: Mon Mar 3 11:18:10 2014 +0100 >>>> >>>> drm/i915: reverse dp link param selection, prefer fast over wide again >>>> >>>> The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at >>>> 2.7 Gbps on the affected machines. Link training succeeded for both, but >>>> the screen remained blank with the former config. Further investigation >>>> showed that 4 lanes at 5.4 Gbps worked also. >>>> >>>> The root cause for the blank screen using 2 lanes remains unknown, but >>>> apparently the driver for a certain other operating system by default >>>> uses the max available lanes. Follow suit on Broadwell eDP, for at least >>>> until we figure out what is going on. > > Uggh, okay this lane thing is such a pita, > > On haswell the Lenovo dock in SST mode is broken by the original patch as well. > > I'm not sure we want to do IS_HASWELL here as well, > > I think we need to revert 38aecea0ccbb909d635619cba22f1891e589b434 Actually adding IS_HASWELL won't work since this problem is with a standard DP port. I'll send the reverts, though I've no idea if this another revert of a revert etc. Dave.
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9f67b724dc28..6eaefca0048d 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -849,7 +849,12 @@ intel_dp_compute_config(struct intel_encoder *encoder, bpp = dev_priv->vbt.edp_bpp; } - if (dev_priv->vbt.edp_lanes) { + if (IS_BROADWELL(dev)) { + /* Yes, it's an ugly hack. */ + min_lane_count = max_lane_count; + DRM_DEBUG_KMS("forcing lane count to max (%u) on BDW\n", + min_lane_count); + } else if (dev_priv->vbt.edp_lanes) { min_lane_count = min(dev_priv->vbt.edp_lanes, max_lane_count); DRM_DEBUG_KMS("using min %u lanes per VBT\n",