Created attachment 98310 [details]
video which shows screen flickering

Created attachment 98311 [details]
partial dmesg with drm.debug=0xe

Forgot to say that my laptop has 12Gb of RAM and is booted using EFI.

Created attachment 98312 [details]
intel_reg_dumper output

dmesg output:
[  589.886383] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[  589.886393] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c400c
[  589.886401] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[  589.886409] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c400c
[  589.886412] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[  589.886415] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to c400c
[  589.886426] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to 44004
[  589.886429] [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to 44004
[  589.886443] [drm:hsw_unclaimed_reg_check] *ERROR* Unclaimed write to c400c
[  589.886554] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[  589.886555] [drm:hsw_unclaimed_reg_clear] *ERROR* Unknown unclaimed register before writing to 4400c
[  589.886616] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt
[  589.886642] [drm:intel_uncore_check_errors] *ERROR* Unclaimed register before interrupt

Tested on kernel-3.15-rc3: no difference.

kernel-3.9.11 and older - the issue is absent;
kernel 3.10.0 and newer - the issue is present.

(In reply to comment #6)
> kernel-3.9.11 and older - the issue is absent;
> kernel 3.10.0 and newer - the issue is present.

If you are able to bisect the first bad commit, it will help us root cause this faster.

I digged out the first bad commit patch-by-patch. In particular, this page is interesting:
http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-next&qt=grep&q=&ofs=55250

The last good commit was "lguest: improve code readability in lg_cpu_start". The first bad commit is "drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth", here is a direct link:
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=67d411ddb9def691572cd5ad0ee2991510d860d2

I apologize for forgetting to resolve git branches. In fact, a relevant page is here:
http://cgit.freedesktop.org/drm-intel/log/?h=drm-intel-next&id=bae3699182027525d92b97d904578a533264b242&qt=committer&q=Vetter

and the first bad commit is "drm/i915: convert DP autodither code to new infrastructure". The patch can be found here:
http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next&id=3600836585e3fdef0a1410d63fe5ce4015007aac

(In reply to comment #9)
> and the first bad commit is "drm/i915: convert DP autodither code to new
> infrastructure". The patch can be found here:
> http://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-
> next&id=3600836585e3fdef0a1410d63fe5ce4015007aac

Please attach intel_reg_dumper output for 1) running the bad commit

commit 3600836585e3fdef0a1410d63fe5ce4015007aac
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:59 2013 +0100

    drm/i915: convert DP autodither code to new infrastructure

and 2) the immediately preceding commit that I presume is good

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:58 2013 +0100

    drm/i915: precompute pipe bpp before touching the hw

and finally 3) running current drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel.

I'm sorry if this is a bit laborous, but this seems hard to figure out otherwise.

Created attachment 98551 [details]
intel_reg_dumper output: the last good commit

Created attachment 98552 [details]
intel_reg_dumper output: the first bad commit

Created attachment 98553 [details]
intel_reg_dumper output: the nightly commit d8aaef4e612a004325293ddf9b7f36cf87d991f0

Just is case: for the "last good"/"first bad" linux kernel, the screen resolution is correct, but framebuffer occupies only approximately 2/3 of height and width of the screen. For the nightly kernel, this problem is absent.

For the last good kernel:
[drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 141000KHz
[drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24
[drm:intel_dp_compute_config], DP link bw required 338400 available 432000


For the first bad & the nightly kernel:
[drm:intel_dp_compute_config], DP link computation with max lane count 2 max bw 0a pixel clock 141000KHz
[drm:intel_dp_compute_config], DP link bw 06 lane count 2 clock 162000 bpp 18
[drm:intel_dp_compute_config], DP link bw required 253800 available 259200

Might the problem be related to bpp which changed from 24 to 18?

I forced bpp to 24:

diff -Naur drivers1/gpu/drm/i915/intel_display.c drivers2/gpu/drm/i915/intel_display.c
--- drivers1/gpu/drm/i915/intel_display.c	2014-05-06 14:08:26.000000000 +0200
+++ drivers2/gpu/drm/i915/intel_display.c	2014-05-06 14:09:26.000000000 +0200
@@ -8188,6 +8188,8 @@
 		pipe_config->pipe_bpp = connector->base.display_info.bpc*3;
 	}
 
+	pipe_config->pipe_bpp = 24;
+
 	/* Clamp bpp to 8 on screens without EDID 1.4 */
 	if (connector->base.display_info.bpc == 0 && bpp > 24) {
 		DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit of 24\n",
diff -Naur drivers1/gpu/drm/i915/intel_dp.c drivers2/gpu/drm/i915/intel_dp.c
--- drivers1/gpu/drm/i915/intel_dp.c	2014-05-06 14:22:16.000000000 +0200
+++ drivers2/gpu/drm/i915/intel_dp.c	2014-05-06 14:23:29.000000000 +0200
@@ -748,6 +748,8 @@
 		bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);
 	}
 
+	bpp = 24;
+
 	for (; bpp >= 6*3; bpp -= 2*3) {
 		mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
 
Screen flickering disappeared, but I see sharp color transitions on pictures with smoothly changing color. So bpp=18 was correct, thereas some other parameters were problematic. Probably, those lines are important:

[    1.332972] [drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24
[    1.332973] [drm:intel_dp_compute_config], DP link bw required 338400 available 432000

A problem of bandwidth?

The following temporary workaround prevents screen flickering:

--- intel_dp.c.orig	2014-05-06 16:36:52.969995358 +0200
+++ intel_dp.c	2014-05-06 16:45:11.209995061 +0200
@@ -749,7 +749,7 @@
 	}
 
 	for (; bpp >= 6*3; bpp -= 2*3) {
-		mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp);
+		mode_rate = intel_dp_link_required(adjusted_mode->clock, bpp +6);
 
 		for (clock = 0; clock <= max_clock; clock++) {
 			for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {

but now I get the following messages when running an OpenGL application:

[drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags(DRM_MODE_FLAG_PHSYNC) (expected 0, found 1)
 ------------[ cut here ]------------
WARNING: CPU: 0 PID: 3663 at drivers/gpu/drm/i915/intel_display.c:8853 check_crtc_state+0x65f/0xb50()
pipe state doesn't match!

I am thinking that if we hit too close to the boundary in your case.

Could you give this a spin:

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 34ed143..6310543 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -819,7 +819,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
                                link_avail = intel_dp_max_data_rate(link_clock,
                                                                    lane_count);
 
-                               if (mode_rate <= link_avail) {
+                               if (mode_rate * 11 <= link_avail * 10) {
                                        goto found;
                                }
                        }

This patch works, no screen flickering.

[drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 18
[drm:intel_dp_compute_config], DP link bw required 253800 available 432000
[drm:intel_modeset_pipe_config], plane bpp: 24, pipe bpp: 18, dithering: 1

Can you please retest with latest drm-intel-fixes from

http://cgit.freedesktop.org/drm-intel

I specifically wonder about the vbt-based edp settings.

I tried drm-intel-nightly 6090912409714e19c6f5729952d23b457ad41712: no screen flickering, but the kernel panics right after KMS (I had about two seconds to do tests). Attaching a photo with the kernel message.

Do you want me to test a particular earlier version of drm-intel-nightly?

Created attachment 99158 [details]
kernel panic, drm-intel-6090912409714e19c6f5729952d23b457ad41712

(In reply to comment #20)
> Can you please retest with latest drm-intel-fixes from
> 
> http://cgit.freedesktop.org/drm-intel
> 
> I specifically wonder about the vbt-based edp settings.

Ugh, that's bad. Can you please try to bisect where this regression with the kernel panic was introduced?

No more hangs with the latest intel-drm-nightly, no screen flickering.
Thanks and sorry for the delay!

Please, let me know if you want me to test anything else.

Closing is all that's needed, thanks for the report and testing.

Closing resolved+fixed, verification done by Reporter.