Iirc this is a regression, right? If so can you please bisect this?

(In reply to comment #1)
> Iirc this is a regression, right? If so can you please bisect this?

I'm sorry, currently we are using a monitor newer than the former, and there's much more modes on the newer monitor. I think this issue is exist for a long time, and I have tested many older -next-queued kernels, all reproducible. I can't find a good commit.

Is this really only on Ironlake? HSW, IVB and SNB work fine with it?

(In reply to comment #3)
> Is this really only on Ironlake? HSW, IVB and SNB work fine with it?

Kernel:
-----------------
Kernel: (drm-intel-nightly)815ca9817afc1c1a45799fb9d4a4f413b7b1517c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 14 14:14:04 2013 +0200

    drm/i915: inline vma_create into lookup_or_create_vma

Description:
-----------------
Monitor Version No: VE228Q-C

There's also some mode can't light up on other machines.

SNB unlighted mode:
CRTS(3):[28]  720x480 60 720 736 798 858 480 489 495 525 0xa 0x40 27000
CRTS(3):[30]  640x480 73 640 664 704 832 480 489 491 520 0xa 0x40 31500


IVB unlighted mode:
CRTS(3):[19]  1024x768 70 1024 1048 1184 1328 768 771 777 806 0xa 0x40 75000
CRTS(3):[23]  800x600 72 800 856 976 1040 600 637 643 666 0x5 0x40 50000
CRTS(3):[29]  640x480 75 640 656 720 840 480 481 484 500 0xa 0x40 31500
CRTS(3):[31]  640x480 67 640 704 768 864 480 483 486 525 0xa 0x40 30240
CRTS(3):[33]  640x480 60 640 656 752 800 480 490 492 525 0xa 0x40 25175
CRTS(3):[34]  720x400 70 720 738 846 900 400 412 414 449 0x6 0x40 28320

HSW all passed.

This bug also exists on this round testing.

Wonder if this is an issue with our wide vs narrow config?  If so, this patch might help:


diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cbf33be..44b3d95 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -847,8 +847,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
 						   bpp);
 
-		for (clock = 0; clock <= max_clock; clock++) {
-			for (lane_count = 1; lane_count <= max_lane_count;  lane_count <<= 1) {
+		for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
+			for (clock = 0; clock <= max_clock; clock++) {
 				link_clock = drm_dp_bw_code_to_link_rate(bws[clock]);
 				link_avail = intel_dp_max_data_rate(link_clock,
 								    lane_count);

Also general request to retest on latest -nightly, there's been a few bugfixes in the area ...

Created attachment 89519 [details]
Dmesg of next-queued kernel with patch

I applied your patch( gived in comment 6) to latest drm-intel-next-queued branch. But there's still some mode cannot light up.
Mode which can't light up:
[0]  2560x1600 60 2560 2608 2640 2720 1600 1603 1609 1646 0x9 0x48 268500
[1]  1920x1440 60 1920 2048 2256 2600 1440 1441 1444 1500 0x6 0x40 234000
[2]  1920x1200 60 1920 2056 2256 2592 1200 1203 1209 1245 0x6 0x40 193250
[3]  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 0x5 0x40 148500
[5]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74250
[6]  1920x1080i 60 1920 2008 2052 2200 1080 1084 1094 1125 0x15 0x40 74176
[7]  1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 0x5 0x40 148500
[8]  1920x1080i 50 1920 2448 2492 2640 1080 1084 1094 1125 0x15 0x40 74250
[12]  1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 0x5 0x40 135000

Could you please test with latest drm-intel-nightly?

We have test on nightly ,all resolution of DP can display normally.

Closing old verified.