[Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking
Ville Syrjälä
ville.syrjala at linux.intel.com
Mon Feb 15 20:26:33 UTC 2016
On Mon, Feb 15, 2016 at 08:17:23PM +0100, Tore Anderson wrote:
> Hello,
>
> Since upgrading to the Fedora 4.3 kernel package, the picture on my the
> BenQ M2700 HD monitor I've got connected to my HP EliteBook Folio 9470m
> laptop began having issues. The monitor is connected with a DP+-to-HDMI
> cable (HDMI in the monitor end), and the resolution I'm using is
> 1920x1080.
>
> The symptoms are brief flickers of which looks like a thin horizontal
> line (or maybe more) overlaying the picture for a very brief period.
> This is ofte often (but not always) followed by the entire picture
> going completely black (kind of like when xscreensaver blanks the
> screen). Usually, the picture returns after maybe a second, but
> sometimes it remains off for several seconds before returning. It might
> also be that these blankings happen without a horizontal line flicker
> having occurred immediately before, thought it's hard to be certain
> because the flickers are very brief.
>
> The laptop's internal screen is not impacted, the picture there remains
> stable while the external screen is flickering/blanking (including if
> both screens are set up in xrandr to show the same output).
>
> Most of the time the flickers and blankings happens only occasionally,
> and be just a minor annoyance. However, some times it gets really bad,
> and the screen spends a majority of the time black - making it
> impossible to use the system. I have not determined anything that will
> with 100% certainty cause the symptoms to manifest themselves, but I do
> have a feeling that it is more likely to happen if the picture is
> mostly white/bright (e.g., when displaying a web browser window or an
> application such as gitk), and also after having resumed from suspend.
> But flickering/blanking certainly does happen if the screen showing
> mostly black xterms and without having suspended/resumed too.
>
> I bisected the problem, which resulted in the following verdict:
>
> 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67 is the first bad commit
> commit 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67
> Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Date: Tue Jun 30 15:33:54 2015 +0300
>
> Revert "drm/i915: Disable 12bpc hdmi for now"
>
> HDMI 12bpc should be working fine now. Let it loose.
>
> This reverts commit 5e3daaca09f5158eff9c92290faa1d2001ecc6e4.
>
> v2: Rebased due to CHV/BXT port clock check improvemnts
>
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> Reviewed-and-tested-by: Imre Deak <imre.deak at intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> I also confirmed that the problem is still present in drm-intel-nightly
> as of today (8ed1804). I'm currently running 8ed1804 + 7a0baa6 reverted
> and the symptoms are gone.
>
> I've uploaded a kernel logs with drm.debug=0xe here:
>
> http://filebin.net/r3nlwu09y2
>
> One file is from when running 8ed1804 (with some comments of when the symptoms
> occurred added by me), the other file is from right now (running
> 8ed1804 + 7a0baa6 reverted) - I've not yet experienced any issues since
> booting the system with this kernel.
Could you test the following hack while using a 1920x1080 mode with 148.5 MHz
dotclock, and see if there's any improvement?
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4e1321b96522..ea24de873e14 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12842,6 +12842,11 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
clear_intel_crtc_state(pipe_config);
+ if (pipe_config->base.adjusted_mode.clock == 148500) {
+ DRM_ERROR("adjusting dotclock\n");
+ pipe_config->base.adjusted_mode.clock = 148800;
+ }
+
pipe_config->cpu_transcoder =
(enum transcoder) to_intel_crtc(crtc)->pipe;
--
Ville Syrjälä
Intel OTC
More information about the Intel-gfx
mailing list