Hi, On Wed, Jul 04, 2012 at 10:39:49AM -0500, Jonathan Nieder wrote: > Hi again, > > Peter Colberg wrote: > > > cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit > > How about the attached patch --- does it work against the linux-3.2.y > branch? > > Grateful, > Jonathan
> From: Jesse Barnes <jbar...@virtuousgeek.org> > Date: Thu, 21 Jun 2012 15:13:50 -0700 > Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs > > commit 684aaa646f90f5ee07799d52d0735625756e607b upstream. > > High frequency link configurations have the potential to cause trouble > with long and/or cheap cables, so prefer slow and wide configurations > instead. This patch has the potential to cause trouble for eDP > configurations that lie about available lanes, so if we run into that we > can make it conditional on eDP. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801 > Tested-by: pe...@colberg.org > Signed-off-by: Jesse Barnes <jbar...@virtuousgeek.org> > Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> > Signed-off-by: Jonathan Nieder <jrnie...@gmail.com> > --- > drivers/gpu/drm/i915/intel_dp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index d4c4937067fb..fae2050324bc 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct > drm_display_mode *mode, > > bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24; > > - for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) { > - for (clock = 0; clock <= max_clock; clock++) { > + for (clock = 0; clock <= max_clock; clock++) { > + for (lane_count = 1; lane_count <= max_lane_count; lane_count > <<= 1) { > int link_avail = > intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count); > > if (intel_dp_link_required(mode->clock, bpp) > -- > 1.7.11.rc3 I tested upstream linux 3.2.23 with the above patch applied, and the display is working fine, i.e. it comes up in maximum, native resolution even after power-cycling the display. Regards, Peter -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120717221021.GA4476@alcyone