Hello I updated my kernel to 3.16.0-rc5 (drm-intel-nighlty from 18th July 2014 ) and the screen is blurry screen or flickering. I had similar problem a few months - here is link https://bugs.freedesktop.org/show_bug.cgi?id=75378 After bisecting kernel between commit git bisect bad 8734408c113bb38234ed03ec51c723b3deff579b and git bisect good 2d9772ef653ccf2d5213603e371bbdfe7573df93 I tracked the first kernel version with screen defect to [f2c234571d3329204bea7b917cba7004d753c0fc] Merge remote-tracking branch 'origin/drm-intel-fixes' into drm-intel-nightly Now I'm kinda stuck as I do not fully understand the commits at this point Thanks for any help
Created attachment 103304 [details] revert commit c6930992948adf0f8fc1f6ff1da51c5002a2cf95
I found the problem on my computer Toshipa S70 with VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) was caused by commit c6930992948adf0f8fc1f6ff1da51c5002a2cf95 file drivers/gpu/drm/i915/intel_dp.c sequence around loop for (clock = min_clock; clock <= max_clock; clock++) { for (lane_count = min_lane_count; lane_count <= max_lane_count; lane_count <<= 1) { Reversing this commit solved the problem, I recompiled the the drim-intel-nightly (8734408c113bb38234ed03ec51c723b3deff579b) and it works fine. The error is reproducible, ie. by swithcing the sequence of the loops I can reproduce the blury screen or flicker
Note this is a case where the earlier regression triumphs, and so this bug must persist until the root cause is known (i.e. we can fix this without breaking working machines).
(In reply to comment #3) > Note this is a case where the earlier regression triumphs, and so this bug > must persist until the root cause is known (i.e. we can fix this without > breaking working machines). Is there anything I can do to help?
(In reply to comment #4) > (In reply to comment #3) > > Note this is a case where the earlier regression triumphs, and so this bug > > must persist until the root cause is known (i.e. we can fix this without > > breaking working machines). > > Is there anything I can do to help? I presume this is the laptop panel. Please try this patch: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d7fc2c0e9ba8..f4248d7f64f9 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -889,23 +889,13 @@ intel_dp_compute_config(struct intel_encoder *encoder, bpp = dev_priv->vbt.edp_bpp; } - 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", - min_lane_count); - } - - if (dev_priv->vbt.edp_rate) { - min_clock = min(dev_priv->vbt.edp_rate >> 3, max_clock); - DRM_DEBUG_KMS("using min %02x link bw per VBT\n", - bws[min_clock]); - } + /* + * Use the maximum clock and number of lanes the eDP panel + * advertizes being capable of. Typically these values + * correspond to the native resolution of the panel. + */ + min_lane_count = max_lane_count; + min_clock = max_clock; } for (; bpp >= 6*3; bpp -= 2*3) {
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Note this is a case where the earlier regression triumphs, and so this bug > > > must persist until the root cause is known (i.e. we can fix this without > > > breaking working machines). > > > > Is there anything I can do to help? > > I presume this is the laptop panel. Please try this patch: > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c > index d7fc2c0e9ba8..f4248d7f64f9 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -889,23 +889,13 @@ intel_dp_compute_config(struct intel_encoder *encoder, > bpp = dev_priv->vbt.edp_bpp; > } > > - 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", > - min_lane_count); > - } > - > - if (dev_priv->vbt.edp_rate) { > - min_clock = min(dev_priv->vbt.edp_rate >> 3, max_clock); > - DRM_DEBUG_KMS("using min %02x link bw per VBT\n", > - bws[min_clock]); > - } > + /* > + * Use the maximum clock and number of lanes the eDP panel > + * advertizes being capable of. Typically these values > + * correspond to the native resolution of the panel. > + */ > + min_lane_count = max_lane_count; > + min_clock = max_clock; > } > > for (; bpp >= 6*3; bpp -= 2*3) { Yes, this is a laptop. Your patch is working, I used the drm-intel-nightly (2014y-09m-03d-15h-44m-26s SHA1 ID: 4144c90b76dfe6eaa2205ac947090786b5091cff) for testing Thanks
so it should have been fixed by https://bugs.freedesktop.org/show_bug.cgi?id=79386#c16 *** This bug has been marked as a duplicate of bug 79386 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.