Bug 45801 - [SNB DP regression] no signal via DisplayPort since Linux 3.2
[SNB DP regression] no signal via DisplayPort since Linux 3.2
Status: RESOLVED FIXED
Product: DRI
Classification: Unclassified
Component: DRM/Intel
XOrg 6.7.0
x86-64 (AMD64) Linux (All)
: highest major
Assigned To: Jesse Barnes
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-08 13:13 UTC by peter
Modified: 2012-08-05 11:24 UTC (History)
9 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg.0.log under Linux v3.2 (29.83 KB, text/plain)
2012-02-08 13:13 UTC, peter
no flags Details
dmesg output under Linux 3.2 (122.91 KB, text/plain)
2012-02-08 13:14 UTC, peter
no flags Details
Xorg.0.log under Linux v3.1 (29.81 KB, text/plain)
2012-02-08 13:14 UTC, peter
no flags Details
dmesg output under Linux 3.1 (122.91 KB, text/plain)
2012-02-08 13:15 UTC, peter
no flags Details
dmesg output under Linux v3.2-rc2-11398-ge57b688 (122.93 KB, text/plain)
2012-02-08 14:50 UTC, peter
no flags Details
Xorg.0.log under Linux v3.2-rc2-11398-ge57b688 (31.28 KB, text/plain)
2012-02-08 14:51 UTC, peter
no flags Details
xrandr --verbose under Linux v3.2-rc2-11398-ge57b688 (7.17 KB, text/plain)
2012-02-08 14:51 UTC, peter
no flags Details
recompute 6bpc dithering in mode_fixup (3.37 KB, patch)
2012-04-09 08:48 UTC, Daniel Vetter
no flags Details | Splinter Review
dmesg output with Linux 3.4-rc3 (304.78 KB, text/plain)
2012-04-19 11:34 UTC, peter
no flags Details
dmesg output with Linux 3.4-rc3 (of a single boot) (192.54 KB, text/plain)
2012-04-19 11:39 UTC, peter
no flags Details
print computed bpp, too (1.08 KB, patch)
2012-04-20 02:10 UTC, Daniel Vetter
no flags Details | Splinter Review
print computed bpp, too 3 (2.59 KB, patch)
2012-04-20 11:09 UTC, Daniel Vetter
no flags Details | Splinter Review
dmesg output with Linux 3.4-rc3 with [PATCH] drm/i915: print computed bpp in dp link configuration (180.81 KB, text/plain)
2012-04-20 13:39 UTC, peter
no flags Details
force the old dp link configuration (725 bytes, patch)
2012-04-22 04:19 UTC, Daniel Vetter
no flags Details | Splinter Review
Linux 3.4-rc3 override intel_dp->link_bw = 0x06, intel_dp->lane_count = 4 (207.60 KB, text/plain)
2012-04-22 07:49 UTC, peter
no flags Details
printk if sink request a dp link test (417 bytes, patch)
2012-05-13 09:57 UTC, Daniel Vetter
no flags Details | Splinter Review
Linux 3.4-rc3 with printk() in intel_dp_handle_test_request_dmesg (179.11 KB, text/plain)
2012-05-13 12:09 UTC, peter
no flags Details
prefer many lanes and slow clocks to fast clocks with few lanes (800 bytes, patch)
2012-06-21 11:59 UTC, Jesse Barnes
no flags Details | Splinter Review
Linux 3.4.0-rc3 with patch "prefer many lanes and slow clocks to fast clocks with few lanes" (177.11 KB, text/plain)
2012-06-21 13:05 UTC, peter
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description peter 2012-02-08 13:13:26 UTC
Created attachment 56766 [details]
Xorg.0.log under Linux v3.2

This regression was first reported as http://bugs.debian.org/658662

Since upgrading to Linux 3.2, an external display connected via DisplayPort to a Sandy Bridge onboard graphics card stopped working, and instead turns off reporting “DP no signal”.

With Linux 3.1, the same display connected via the DisplayPort works fine. After powering both the display and the machine, the display first turns on when the i915 kernel module is loaded upon boot. It shows the console with boot messages at the maximum display resolution (1920x1080). Then the X server starts, and the external display switches to a lower resolution (1024x768), which seems to be the default setting of the X server. After login, I manually switch to the maximum resolution (1920x1080) using the command “xrandr --output DP1 --auto”.

With Linux 3.2, after powering both the display and the machine, the display remains dark during boot, even when the i915 kernel module is loaded. The display first turns on only when the X server is loaded, with the default resolution 1024x768. After login, I manually switch to 1920x1080, but then the display reports “DP no signal” and turns *off*.

To summarize: The external display connected via DisplayPort works fine with Linux 3.1, while, with Linux 3.2, it works with lower (non-native) resolutions and fails with the maximum (native) resolution.

I noticed one peculiarity: It is possible to have a working external display by booting into Linux 3.1 first, and then rebooting into Linux 3.2 *without interrupting the power supply of the display*. However, as soon as I power-cycle the display while under Linux 3.2, it stops working again.


There is a recent thread by Keith Packard with DisplayPort-related patches:

https://lkml.org/lkml/2012/1/25/204

I tested both a kernel with only PATCH 1/2, as well as a kernel with both PATCH 1/2 and 2/2 applied, based on the Debian kernel source (linux-2.6_3.2.2-1) and using the Debian test-patches script. Both kernels showed the same faulty behaviour, i.e. the external display remains dark at the native resolution.


Grepping for “display port” in the output of dmesg, I noticed a difference in clock frequencies between Linux v3.1 and v3.2. If I assume correctly, the three events correspond to the initial boot console (1920x1080), the loading
of X (1024x768), and the manual switch to maximum resolution using xrandr (1920x1080).

# grep -i display.*port linux-v3.2-dmesg 
[   12.749764] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000
[   12.750194] [drm:intel_choose_pipe_bpp_dither], clamping display bpc (was -1) to EDID reported max of 8
[   20.656887] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 1 clock 270000
[   20.762319] [drm:intel_choose_pipe_bpp_dither], clamping display bpc (was -1) to EDID reported max of 8
[   36.514078] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000
[   36.627340] [drm:intel_choose_pipe_bpp_dither], clamping display bpc (was -1) to EDID reported max of 8

# grep -i display.*port linux-v3.1-dmesg 
[   12.633926] [drm:intel_dp_mode_fixup], Display port link bw 06 lane count 4 clock 162000
[   12.634356] [drm:intel_choose_pipe_bpp_dither], clamping display bpc (was -1) to EDID reported max of 8
[   20.153953] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 1 clock 270000
[   20.263372] [drm:intel_choose_pipe_bpp_dither], clamping display bpc (was -1) to EDID reported max of 8
[   34.066974] [drm:intel_dp_mode_fixup], Display port link bw 06 lane count 4 clock 162000
[   34.178512] [drm:intel_choose_pipe_bpp_dither], clamping display bpc (was -1) to EDID reported max of 8


For this upstream bug report, I bisected the Linux git sources between versions v3.1 and v3.2.

Testing was done following the instructions by Jonathan Nieder:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658662#29

cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit
commit cd9dde44f47501394b9f0715b6a36a92aa74c0d0
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Oct 14 12:43:49 2011 -0400

    drm/i915/dp: Fix the math in intel_dp_link_required
    
    The previous code was confused about units, which is pretty reasonable
    given that the units themselves are confusing.
    
    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Keith Packard <keithp@keithp.com>

:040000 040000 3c0a0f38fc6482a401340e03fa3fbd687d11eda4 294673b782b3ecc93540f46f7721d385bd30cfac M      drivers

# git bisect log
# bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2
# good: [c3b92c8787367a8bb53d57d9789b558f1295cc96] Linux 3.1
git bisect start 'v3.2' 'v3.1'
# bad: [68d99b2c8efcb6ed3807a55569300c53b5f88be5] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
git bisect bad 68d99b2c8efcb6ed3807a55569300c53b5f88be5
# good: [efb8d21b2c6db3497655cc6a033ae8a9883e4063] Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good efb8d21b2c6db3497655cc6a033ae8a9883e4063
# good: [8686a0e200419322654a75155e2e6f80346a1297] Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good 8686a0e200419322654a75155e2e6f80346a1297
# bad: [f362f98e7c445643d27c610bb7a86b79727b592e] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/hch/vfs-queue
git bisect bad f362f98e7c445643d27c610bb7a86b79727b592e
# good: [ca836a25435ef1b9914840ed0a310c9b6ac261d1] Merge branch 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect good ca836a25435ef1b9914840ed0a310c9b6ac261d1
# good: [c5c42360bc1cb14c7da3186683e9525b33b72656] vmwgfx: Don't pass unused arguments to do_dirty functions
git bisect good c5c42360bc1cb14c7da3186683e9525b33b72656
# bad: [5619a693965b291315685bdfe01a0246ebd7e41e] Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs
git bisect bad 5619a693965b291315685bdfe01a0246ebd7e41e
# bad: [82d165557ef094d4b4dfc05871aee618ec7102b0] drm/i915/dp: Fix eDP on PCH DP on CPT/PPT
git bisect bad 82d165557ef094d4b4dfc05871aee618ec7102b0
# good: [a9e2641dee52cae2db7688a749344365642a5e79] drm/i915: close PM interrupt masking races in the rps work func
git bisect good a9e2641dee52cae2db7688a749344365642a5e79
# good: [75770564c90c45618003267f4cdde4bbc090f1bd] drm/i915: use transcoder select bits on VGA and HDMI on CPT
git bisect good 75770564c90c45618003267f4cdde4bbc090f1bd
# good: [a487928908226df493a3ce145ecf4bb39296714e] drm/i915: remove transcoder PLL mashing from mode_set per specs
git bisect good a487928908226df493a3ce145ecf4bb39296714e
# bad: [a2006cf5a7ad3463e7c1e9da2c4bc90499427558] drm/i915: read full receiver capability field during DP hot plug
git bisect bad a2006cf5a7ad3463e7c1e9da2c4bc90499427558
# good: [f52c619a590fa75276c07dfcaf380dee53e4ea4c] drm/i915/panel: Always record the backlight level again (but cleverly)
git bisect good f52c619a590fa75276c07dfcaf380dee53e4ea4c
# bad: [dc22ee6fc18ce0f15424e753e8473c306ece95c1] drm/i915/dp: Remove eDP special cases from bandwidth checks
git bisect bad dc22ee6fc18ce0f15424e753e8473c306ece95c1
# bad: [cd9dde44f47501394b9f0715b6a36a92aa74c0d0] drm/i915/dp: Fix the math in intel_dp_link_required
git bisect bad cd9dde44f47501394b9f0715b6a36a92aa74c0d0


System environment: 
-- chipset: GT2+
-- system architecture: x86_64
-- xf86-video-intel: 2.17.0
-- xserver: 1.11.3.901
-- mesa: 7.11.2
-- libdrm: 2.4.30
-- kernel: 3.2.0
-- Linux distribution: Debian GNU/Linux testing (wheezy)
-- Machine or mobo model: Intel Sandybridge Mobile
-- Display connector: DisplayPort
Comment 1 peter 2012-02-08 13:14:26 UTC
Created attachment 56767 [details]
dmesg output under Linux 3.2
Comment 2 peter 2012-02-08 13:14:58 UTC
Created attachment 56768 [details]
Xorg.0.log under Linux v3.1
Comment 3 peter 2012-02-08 13:15:31 UTC
Created attachment 56769 [details]
dmesg output under Linux 3.1
Comment 4 Daniel Vetter 2012-02-08 13:25:57 UTC
Sounds like one of the dp bugs we've already fixed in -fixes. Please try the drm-intel-fixes branch from

https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=summary
Comment 5 peter 2012-02-08 14:49:14 UTC
I compiled and tested the drm-intel-fixes branch, and it is still faulty, i.e. the display turns off with “no signal” at the maximum resolution.

# git describe
v3.2-rc2-11398-ge57b688
# uname -a
Linux alcyone 3.3.0-rc1+ #1 SMP Wed Feb 8 22:19:11 UTC 2012 x86_64 GNU/Linux

As I mentioned above, I had tested the DisplayPort fixes of https://lkml.org/lkml/2012/1/25/204 before, and neither of the patches fixed the regression introduced in commit cd9dde4.
Comment 6 peter 2012-02-08 14:50:08 UTC
Created attachment 56777 [details]
dmesg output under Linux v3.2-rc2-11398-ge57b688
Comment 7 peter 2012-02-08 14:51:05 UTC
Created attachment 56778 [details]
Xorg.0.log under Linux v3.2-rc2-11398-ge57b688
Comment 8 peter 2012-02-08 14:51:48 UTC
Created attachment 56779 [details]
xrandr --verbose under Linux v3.2-rc2-11398-ge57b688
Comment 9 Daniel Vetter 2012-02-08 15:05:54 UTC
Can you please try to disable dp audio when switching to the higher resolution, i.e.

xrandr --output DP1 --mode 1920x1080 --set audio off

... or similar.
Comment 10 peter 2012-02-08 15:52:06 UTC
Adding “--set audio off” to xrandr does not help, the display turns off.

Do you have an idea why “count” and “clock” differ in [drm:intel_dp_mode_fixup]?

# Linux v3.1
[   34.066974] [drm:intel_dp_mode_fixup], Display port link bw 06 lane count 4 clock 162000

# Linux v3.2
[   36.514078] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000

# Linux v3.2-rc2-11398-ge57b688 (drm-intel-fixes)
[   34.344424] [drm:intel_dp_mode_fixup], Display port link bw 0a lane count 2 clock 270000
Comment 11 peter 2012-02-15 08:32:13 UTC
For bug CCs not following the intel-gfx mailing list:

http://lists.freedesktop.org/archives/intel-gfx/2012-February/015135.html
Comment 12 peter 2012-02-24 13:12:21 UTC
Hi,

Is there anything I can do in terms of debugging and testing to help resolve this bug? Debian, for example, has recently updated the kernel of its testing suite to Linux 3.2. Users affected by this bug will likely feel increasingly uncomfortable having to downgrade to an unmaintained Linux 3.1 kernel with potentially unfixed security vulnerabilities.

I have tried to revert commit cd9dde4 on the basis of Linux 3.2, but since drm/i915 has undergone quite a few changes since then, this results in conflicts. Which commits would one have to revert in order to cleanly work around the regression introduced by commit cd9dde4?

Thanks for any pointers,
Peter
Comment 13 Jesse Barnes 2012-04-05 17:00:43 UTC
Yeah looks like we're still getting the link bandwidth calculations wrong, probably by using the wrong value somewhere.

I hack to workaround the issue might be to just hard code bpp = 24 in all the calls to intel_dp_link_required().  If that works then it's definitely our problem...
Comment 14 Daniel Vetter 2012-04-09 08:48:52 UTC
Created attachment 59684 [details] [review]
recompute 6bpc dithering in mode_fixup

Please test this patch and attach full dmesg (with drm.debug=0xe added to your kernel cmdline) to the bug. If your issue is indeed due to 6bpc dithering gone wrong, this might fix it.
Comment 15 Jesse Barnes 2012-04-18 11:06:43 UTC
Should be fixed now (at least it works on my T420 now).  Probably due to:

commit c4867936474183332db4c19791a65fdad6474fd5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 10 10:42:36 2012 +0200

    drm/i915: properly compute dp dithering for user-created modes

which went to stable, so should be in the latest 3.3.x and 3.4.x kernels.
Comment 16 peter 2012-04-18 21:19:01 UTC
I tested Linux commit v3.4-rc3, which contains commit c486793.

The issue is *not* resolved in Linux v3.4-rc3.

Please, take a look at my initial report again. The bisect shows that this issue first occurs with commit cd9dde4 (October 2011). Whatever needs to be fixed to resolve this problem, the answer is in commit cd9dde4.

Thanks,
Peter
Comment 17 Daniel Vetter 2012-04-19 00:48:12 UTC
Please boot with drm.debug=0xe added to the kernel cmdline and attach the complete dmesg to this bug report (on 3.4-rc3).
Comment 18 peter 2012-04-19 11:34:18 UTC
Created attachment 60332 [details]
dmesg output with Linux 3.4-rc3

I booted with drm.debug=0xe added to the kernel cmdline (on 3.4-rc3).

The procedure was as follows:

* Reboot from Linux 3.1.8 with DP working at native resolution (1920x1080).

* Boot Linux 3.4-rc3.

* When the i915 is loaded upon boot, the console switches the DP to native resolution, the display works.

* When the X server is loaded, the DP display comes up in 1024x768.

* Switch DP to native resolution using

  xrandr --output DP1 --auto

  As expected, the display still works, *since we have not power-cycled yet*.

* Unplug power cord of display, and replug.

* The display shows the builtin “power-on without signal” screen ("BenQ", "Energy-saving ..."), and than turns off.

* Switch to 1024x768 using

  xrandr --output DP1 --mode 1024x768

* The display turns on in 1024x768 resolution.

* Switch to native resolution using

  xrandr --output DP1 --auto

* The display turns off.

The import bit is the power cycling. When rebooting from a working kernel (3.1) to a broken kernel (3.2, 3.3, 3.4-rc), the DP will continue working in native resolution, until the display is power cycled, and after that fail to turn on in native resolution.
Comment 19 peter 2012-04-19 11:39:12 UTC
Created attachment 60333 [details]
dmesg output with Linux 3.4-rc3 (of a single boot)

I booted with drm.debug=0xe added to the kernel cmdline (on 3.4-rc3).

The procedure was as follows:

* Reboot from Linux 3.1.8 with DP working at native resolution (1920x1080).

* Boot Linux 3.4-rc3.

* When the i915 is loaded upon boot, the console switches the DP to native
  resolution, the display works.

* When the X server is loaded, the DP display comes up in 1024x768.

* Switch DP to native resolution using

  xrandr --output DP1 --auto

  As expected, the display still works, *since we have not power-cycled yet*.

* Unplug power cord of display, and replug.

* The display shows the builtin “power-on without signal” screen ("BenQ",
  "Energy-saving ..."), and than turns off.

* Switch to 1024x768 using

  xrandr --output DP1 --mode 1024x768

* The display turns on in 1024x768 resolution.

* Switch to native resolution using

  xrandr --output DP1 --auto

* The display turns off.

The import bit is the power cycling. When rebooting from a working kernel (3.1) to a broken kernel (3.2, 3.3, 3.4-rc), the DP will continue working in native resolution, until the display is power cycled, and after that fail to turn on in native resolution.
Comment 20 Jesse Barnes 2012-04-19 12:04:37 UTC
I see different behavior (I'm using drm-intel-next-queued).

On boot I get a cloned 1152x864 mode in X.

xrandr --output DP1 --auto switches the DP into 1920x1200

when I unplug the power from the DP monitor, X goes to 1600x900 on the local flat panel.

when I plug the DP monitor back in, it comes up in its native mode.

So I wonder if something is funky with the desktop or X configuration on your system, rather than the kernel...
Comment 21 peter 2012-04-19 12:17:22 UTC
My Xorg configuration is the usual, i.e. there exists no /etc/X11/xorg.conf.

In terms of Xorg configuration, I have these files in /etc/X11/xorg.conf.d/:


# /etc/X11/xorg.conf.d/keyboard.conf

Section "InputClass"
        Identifier      "Ergonomic Keyboard 4000"
        MatchProduct    "Ergonomic Keyboard 4000"

        Option          "XkbModel"      "pc105"
        Option          "XkbLayout"     "us"
        Option          "XkbVariant"    "basic"
        Option          "XkbOptions"    "compose:menu,caps:super"
EndSection

# Section "InputClass"
        Identifier      "Trackpoint"
        MatchProduct    "TrackPoint"

        # Enable vertical scrolling
        Option          "EmulateWheel" "1"
        Option          "EmulateWheelButton" "2"
        Option          "EmulateWheelTimeout" "200"

        # Enable horizontal scrolling
        Option          "XAxisMapping" "6 7"
        Option          "YAxisMapping" "4 5"
EndSection



Could you elaborate on the math “fixed” in commit c486793. What formulas is this commit based on? Could you please explain the details for someone very familiar with math, but not familar with X modes and/or DisplayPort?

Thanks,
Peter
Comment 22 peter 2012-04-19 12:19:07 UTC
This is on an update-to-date Debian wheezy (amd64) system.
Comment 23 Jesse Barnes 2012-04-19 12:34:25 UTC
We need to calculate the bandwidth that will be used by a given mode configuration so we can configure the DP link for the right clock rate and number of lanes.

The fix in commit cd9dde44f47501394b9f0715b6a36a92aa74c0d0 was only a partial one; we were getting the wrong bits per pixel value there until very recently (even now we need to make estimates since we don't have enough information at the time we get called at some points).

What's odd is that in your config, you can get the display to come up in its native mode, which means the calculation is working ok in at least some cases.

Can you check what pixel_clock and bpp values you get in the successful and failing cases?  I wonder if we're failing to propagate data in some cases, or just getting the wrong data altogether...
Comment 24 Daniel Vetter 2012-04-20 02:10:04 UTC
Created attachment 60372 [details] [review]
print computed bpp, too

Thanks a lot for the detailed description, it's excellent. Unfortunately we miss a little bit of debug info, can you please retry with the attached patch applied?

Also, please indicate in your test log the relevant timestamps in dmesg, sometimes it's a bit ambigious to match up what you've done with what's going on in dmesg.
Comment 25 Daniel Vetter 2012-04-20 11:09:27 UTC
Created attachment 60401 [details] [review]
print computed bpp, too 3

Even more debug output.
Comment 26 peter 2012-04-20 13:39:41 UTC
Created attachment 60407 [details]
dmesg output with Linux 3.4-rc3 with [PATCH] drm/i915: print computed bpp in dp link configuration

I tested 3.4-rc3 with the patch applied. This time I waited more than a few seconds between each manual action, and dumped dmesg before and after an action, in order to identify them in the kernel log. I hope it helps with the debugging.
Comment 27 Daniel Vetter 2012-04-22 04:19:59 UTC
Created attachment 60447 [details] [review]
force the old dp link configuration

Quick patch to force the olde (3.1 kernel) dp link configuration to figure out where the problem. Please test whether this works around the problem.
Comment 28 peter 2012-04-22 07:49:23 UTC
Created attachment 60450 [details]
Linux 3.4-rc3 override intel_dp->link_bw = 0x06, intel_dp->lane_count = 4

Please see the kernel log of 3.4-rc3 with intel_dp->link_bw = 0x06, intel_dp->lane_count = 4.

The manual override works, the display turns on (in native resolution) after power cycle :-).
Comment 29 Daniel Vetter 2012-04-22 12:45:55 UTC
Another thing to try (attaching dmesg unnecessary) is to disable audio on the dp link with

xrandr --output DP1 --auto --set audio off
Comment 30 peter 2012-04-22 15:15:42 UTC
Please refer to https://bugs.freedesktop.org/show_bug.cgi?id=45801#c10

Adding “--set audio off” to xrandr does not help, the display turns off.

Is there a way to fix the formula so it computes the correct link_bw and lane_count?
Comment 31 Chris Wilson 2012-05-10 11:18:12 UTC
Hmm, a 10/8 factor for link required would neatly explain the failure. So are we still failing to account for the 10-bit symbol size... The last review suggested that the link clock already included that factor.

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9919fc0..b3200ea 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -210,7 +210,7 @@ intel_dp_link_clock(uint8_t link_bw)
 static int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
-       return (pixel_clock * bpp + 9) / 10;
+       return (pixel_clock * bpp + 9) / 8 * 10 / 10;
 }
Comment 32 Chris Wilson 2012-05-10 11:36:10 UTC
* kicks himself. You identified the very commit I suspected from the stat.
Comment 33 Daniel Vetter 2012-05-13 09:57:39 UTC
Created attachment 61563 [details] [review]
printk if sink request a dp link test

Can you please quickly test this debug patch (on a broken kernel) please and check whether anything ends up in dmesg?
Comment 34 peter 2012-05-13 12:09:46 UTC
Created attachment 61576 [details]
Linux 3.4-rc3 with printk() in intel_dp_handle_test_request_dmesg

Please see the dmesg output, tested with Linux 3.4-rc3 patched to printk() in the function intel_dp_handle_test_request_dmesg.

# git log -1
commit e816b57a337ea3b755de72bec38c10c864f23015
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Apr 15 18:28:29 2012 -0700

    Linux 3.4-rc3

# git diff
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4b63791..847b464 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1973,6 +1973,8 @@ intel_dp_handle_test_request(struct intel_dp *intel_dp)
 {
        /* NAK by default */
        intel_dp_aux_native_write_1(intel_dp, DP_TEST_RESPONSE, DP_TEST_ACK);
+
+       printk("dp link test request received\n");
 }
 
 /*


The output does not contain "dp link test request received", in other words intel_dp_handle_test_request_dmesg is not invoked.
Comment 35 peter 2012-05-13 12:14:21 UTC
For my own notes, to speed up the next test round:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

git checkout v3.4-rc3

cp ...debian.../config-3.2.0-2-amd64 .config

make oldconfig

nice make deb-pkg -j 4 INSTALL_MOD_STRIP=1
Comment 36 peter 2012-05-13 12:16:07 UTC
More notes when testing a (faulty) kernel...


Reboot from Linux 3.1.8 with DP working at native resolution (1920x1080).

Boot Linux <version>.

When the i915 is loaded upon boot, the console switches the DP to native resolution, the display works.

When the X server is loaded, the DP display comes up in 1024x768.


Switch DP to native resolution using

xrandr --output DP1 --auto

As expected, the display still works, since we have not power-cycled yet.


Unplug power cord of display,


and replug.

The display shows the builtin “power-on without signal” screen ("BenQ",
"Energy-saving ..."), and than turns off.


Switch to 1024x768 using

xrandr --output DP1 --mode 1024x768

The display turns on in 1024x768 resolution.


Switch to native resolution using

xrandr --output DP1 --auto

The display turns off.
Comment 37 Jonathan Nieder 2012-05-13 12:18:59 UTC
bugzilla-daemon@freedesktop.org wrote:

> For my own notes, to speed up the next test round:

Some quick unsolicited tips: ;-)

> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

No need to clone each time --- "git reset --hard" in an existing
clone will clear away any changes.

> git checkout v3.4-rc3
> cp ...debian.../config-3.2.0-2-amd64 .config
> make oldconfig
> nice make deb-pkg -j 4 INSTALL_MOD_STRIP=1

"make localmodconfig" can make for faster builds.  (It disables
modules that are not currently loaded, which presumably are for
hardware you don't have or don't use.)  "scripts/config --disable
DEBUG_INFO" can be used to make the build take less disk space.
Comment 38 peter 2012-05-13 12:27:38 UTC
Hi Jonathan,

(In reply to comment #37)
> > git checkout v3.4-rc3
> > cp ...debian.../config-3.2.0-2-amd64 .config
> > make oldconfig
> > nice make deb-pkg -j 4 INSTALL_MOD_STRIP=1
> 
> "make localmodconfig" can make for faster builds.  (It disables
> modules that are not currently loaded, which presumably are for
> hardware you don't have or don't use.)  "scripts/config --disable
> DEBUG_INFO" can be used to make the build take less disk space.

Thanks, your hints are much appreciated for the next testing ;-).

Peter
Comment 39 Daniel Vetter 2012-05-21 09:19:18 UTC
Can you please give us specific details about your monitors make&model and serial number?
Comment 40 peter 2012-06-14 11:12:13 UTC
Sorry for the delay. This is the information from Xorg.0.log for DP1:

[    51.192] (II) intel(0): EDID for output DP1
[    51.192] (II) intel(0): Manufacturer: BNQ  Model: 8002  Serial#: 21573
[    51.192] (II) intel(0): Year: 2010  Week: 42
[    51.192] (II) intel(0): EDID Version: 1.4
[    51.192] (II) intel(0): Digital Display Input
[    51.192] (II) intel(0): 8 bits per channel
[    51.192] (II) intel(0): Digital interface is DisplayPort
[    51.192] (II) intel(0): Max Image Size [cm]: horiz.: 53  vert.: 30
[    51.192] (II) intel(0): Gamma: 2.20
[    51.192] (II) intel(0): DPMS capabilities: Off
[    51.192] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 YCrCb 4:2:2
[    51.192] (II) intel(0): Default color space is primary color space
[    51.192] (II) intel(0): First detailed timing is preferred mode
[    51.192] (II) intel(0): Preferred mode is native pixel format and refresh rate
[    51.192] (II) intel(0): redX: 0.643 redY: 0.339   greenX: 0.329 greenY: 0.624
[    51.192] (II) intel(0): blueX: 0.155 blueY: 0.048   whiteX: 0.313 whiteY: 0.329
[    51.192] (II) intel(0): Supported established timings:
[    51.192] (II) intel(0): 640x480@60Hz
[    51.192] (II) intel(0): 800x600@60Hz
[    51.192] (II) intel(0): 1024x768@60Hz
[    51.192] (II) intel(0): Manufacturer's mask: 0
[    51.192] (II) intel(0): Supported standard timings:
[    51.192] (II) intel(0): #0: hsize: 1280  vsize 800  refresh: 60  vid: 129
[    51.192] (II) intel(0): #1: hsize: 1280  vsize 720  refresh: 60  vid: 49281
[    51.192] (II) intel(0): #2: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
[    51.193] (II) intel(0): #3: hsize: 1600  vsize 900  refresh: 60  vid: 49321
[    51.193] (II) intel(0): #4: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[    51.193] (II) intel(0): #5: hsize: 1920  vsize 1080  refresh: 60  vid: 49361
[    51.193] (II) intel(0): Supported detailed timing:
[    51.193] (II) intel(0): clock: 148.5 MHz   Image Size:  477 x 268 mm
[    51.193] (II) intel(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 h_blank_end 2200 h_border: 0
[    51.193] (II) intel(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
[    51.193] (II) intel(0): Serial No: SAA04093SL0
[    51.193] (II) intel(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz
[    51.193] (II) intel(0): Monitor name: BenQ BL2400
[    51.193] (II) intel(0): EDID (in hex):
[    51.193] (II) intel(0):     00ffffffffffff0009d1028045540000
[    51.193] (II) intel(0):     2a140104a5351e783eb7d5a456549f27
[    51.193] (II) intel(0):     0c5054210800810081c08180a9c0b300
[    51.193] (II) intel(0):     d1c001010101023a801871382d40582c
[    51.193] (II) intel(0):     4500dd0c1100001e000000ff00534141
[    51.193] (II) intel(0):     3034303933534c300a20000000fd0032
[    51.193] (II) intel(0):     4c1e5311000a202020202020000000fc
[    51.193] (II) intel(0):     0042656e5120424c323430300a2000d4
[    51.193] (II) intel(0): Printing probed modes for output DP1
[    51.193] (II) intel(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[    51.193] (II) intel(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
[    51.193] (II) intel(0): Modeline "1600x900"x60.0  118.96  1600 1696 1864 2128  900 901 904 932 -hsync +vsync (55.9 kHz)
[    51.193] (II) intel(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[    51.193] (II) intel(0): Modeline "1280x800"x59.8   83.50  1280 1352 1480 1680  800 803 809 831 +hsync -vsync (49.7 kHz e)
[    51.193] (II) intel(0): Modeline "1280x720"x60.0   74.44  1280 1336 1472 1664  720 721 724 746 -hsync +vsync (44.7 kHz)
[    51.193] (II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[    51.193] (II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[    51.193] (II) intel(0): Modeline "640x480"x60.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)


This is the output from xrandr --verbose for DP1:

DP1 connected 1920x1080+0+0 (0x50) normal (normal left inverted right x axis y axis) 477mm x 268mm
        Identifier: 0x44
        Timestamp:  95529
        Subpixel:   unknown
        Gamma:      1.0:1.0:1.0
        Brightness: 1.0
        Clones:
        CRTC:       1
        CRTCs:      0 1
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter:
        EDID:
                00ffffffffffff0009d1028045540000
                2a140104a5351e783eb7d5a456549f27
                0c5054210800810081c08180a9c0b300
                d1c001010101023a801871382d40582c
                4500dd0c1100001e000000ff00534141
                3034303933534c300a20000000fd0032
                4c1e5311000a202020202020000000fc
                0042656e5120424c323430300a2000d4
        Broadcast RGB:  Full
                supported: Full         Limited 16:2
        audio:  auto
                supported: off          auto         on
  1920x1080 (0x50)  148.5MHz +HSync +VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   60.0Hz
  1680x1050 (0x51)  146.2MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
  1600x900 (0x52)  119.0MHz -HSync +VSync
        h: width  1600 start 1696 end 1864 total 2128 skew    0 clock   55.9KHz
        v: height  900 start  901 end  904 total  932           clock   60.0Hz
  1280x1024 (0x53)  108.0MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1280x800 (0x54)   83.5MHz +HSync -VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   49.7KHz
        v: height  800 start  803 end  809 total  831           clock   59.8Hz
  1280x720 (0x55)   74.4MHz -HSync +VSync
        h: width  1280 start 1336 end 1472 total 1664 skew    0 clock   44.7KHz
        v: height  720 start  721 end  724 total  746           clock   60.0Hz
  1024x768 (0x4c)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0x4d)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  640x480 (0x56)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   60.0Hz

Peter
Comment 41 peter 2012-06-14 11:13:21 UTC
On Mon, May 21, 2012 at 04:19:18PM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=45801
> 
> --- Comment #39 from Daniel Vetter <daniel@ffwll.ch> 2012-05-21 09:19:18 PDT ---
> Can you please give us specific details about your monitors make&model and
> serial number?

Sorry for the delay. This is the information from Xorg.0.log for DP1:

[    51.192] (II) intel(0): EDID for output DP1
[    51.192] (II) intel(0): Manufacturer: BNQ  Model: 8002  Serial#: 21573
[    51.192] (II) intel(0): Year: 2010  Week: 42
[    51.192] (II) intel(0): EDID Version: 1.4
[    51.192] (II) intel(0): Digital Display Input
[    51.192] (II) intel(0): 8 bits per channel
[    51.192] (II) intel(0): Digital interface is DisplayPort
[    51.192] (II) intel(0): Max Image Size [cm]: horiz.: 53  vert.: 30
[    51.192] (II) intel(0): Gamma: 2.20
[    51.192] (II) intel(0): DPMS capabilities: Off
[    51.192] (II) intel(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 YCrCb 4:2:2
[    51.192] (II) intel(0): Default color space is primary color space
[    51.192] (II) intel(0): First detailed timing is preferred mode
[    51.192] (II) intel(0): Preferred mode is native pixel format and refresh rate
[    51.192] (II) intel(0): redX: 0.643 redY: 0.339   greenX: 0.329 greenY: 0.624
[    51.192] (II) intel(0): blueX: 0.155 blueY: 0.048   whiteX: 0.313 whiteY: 0.329
[    51.192] (II) intel(0): Supported established timings:
[    51.192] (II) intel(0): 640x480@60Hz
[    51.192] (II) intel(0): 800x600@60Hz
[    51.192] (II) intel(0): 1024x768@60Hz
[    51.192] (II) intel(0): Manufacturer's mask: 0
[    51.192] (II) intel(0): Supported standard timings:
[    51.192] (II) intel(0): #0: hsize: 1280  vsize 800  refresh: 60  vid: 129
[    51.192] (II) intel(0): #1: hsize: 1280  vsize 720  refresh: 60  vid: 49281
[    51.192] (II) intel(0): #2: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
[    51.193] (II) intel(0): #3: hsize: 1600  vsize 900  refresh: 60  vid: 49321
[    51.193] (II) intel(0): #4: hsize: 1680  vsize 1050  refresh: 60  vid: 179
[    51.193] (II) intel(0): #5: hsize: 1920  vsize 1080  refresh: 60  vid: 49361
[    51.193] (II) intel(0): Supported detailed timing:
[    51.193] (II) intel(0): clock: 148.5 MHz   Image Size:  477 x 268 mm
[    51.193] (II) intel(0): h_active: 1920  h_sync: 2008  h_sync_end 2052 h_blank_end 2200 h_border: 0
[    51.193] (II) intel(0): v_active: 1080  v_sync: 1084  v_sync_end 1089 v_blanking: 1125 v_border: 0
[    51.193] (II) intel(0): Serial No: SAA04093SL0
[    51.193] (II) intel(0): Ranges: V min: 50 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 175 MHz
[    51.193] (II) intel(0): Monitor name: BenQ BL2400
[    51.193] (II) intel(0): EDID (in hex):
[    51.193] (II) intel(0):     00ffffffffffff0009d1028045540000
[    51.193] (II) intel(0):     2a140104a5351e783eb7d5a456549f27
[    51.193] (II) intel(0):     0c5054210800810081c08180a9c0b300
[    51.193] (II) intel(0):     d1c001010101023a801871382d40582c
[    51.193] (II) intel(0):     4500dd0c1100001e000000ff00534141
[    51.193] (II) intel(0):     3034303933534c300a20000000fd0032
[    51.193] (II) intel(0):     4c1e5311000a202020202020000000fc
[    51.193] (II) intel(0):     0042656e5120424c323430300a2000d4
[    51.193] (II) intel(0): Printing probed modes for output DP1
[    51.193] (II) intel(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP)
[    51.193] (II) intel(0): Modeline "1680x1050"x60.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz e)
[    51.193] (II) intel(0): Modeline "1600x900"x60.0  118.96  1600 1696 1864 2128  900 901 904 932 -hsync +vsync (55.9 kHz)
[    51.193] (II) intel(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[    51.193] (II) intel(0): Modeline "1280x800"x59.8   83.50  1280 1352 1480 1680  800 803 809 831 +hsync -vsync (49.7 kHz e)
[    51.193] (II) intel(0): Modeline "1280x720"x60.0   74.44  1280 1336 1472 1664  720 721 724 746 -hsync +vsync (44.7 kHz)
[    51.193] (II) intel(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[    51.193] (II) intel(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[    51.193] (II) intel(0): Modeline "640x480"x60.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)


This is the output from xrandr --verbose for DP1:

DP1 connected 1920x1080+0+0 (0x50) normal (normal left inverted right x axis y axis) 477mm x 268mm
        Identifier: 0x44
        Timestamp:  95529
        Subpixel:   unknown
        Gamma:      1.0:1.0:1.0
        Brightness: 1.0
        Clones:    
        CRTC:       1
        CRTCs:      0 1
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        EDID:
                00ffffffffffff0009d1028045540000
                2a140104a5351e783eb7d5a456549f27
                0c5054210800810081c08180a9c0b300
                d1c001010101023a801871382d40582c
                4500dd0c1100001e000000ff00534141
                3034303933534c300a20000000fd0032
                4c1e5311000a202020202020000000fc
                0042656e5120424c323430300a2000d4
        Broadcast RGB:  Full
                supported: Full         Limited 16:2
        audio:  auto
                supported: off          auto         on          
  1920x1080 (0x50)  148.5MHz +HSync +VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
        v: height 1080 start 1084 end 1089 total 1125           clock   60.0Hz
  1680x1050 (0x51)  146.2MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
  1600x900 (0x52)  119.0MHz -HSync +VSync
        h: width  1600 start 1696 end 1864 total 2128 skew    0 clock   55.9KHz
        v: height  900 start  901 end  904 total  932           clock   60.0Hz
  1280x1024 (0x53)  108.0MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1280x800 (0x54)   83.5MHz +HSync -VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   49.7KHz
        v: height  800 start  803 end  809 total  831           clock   59.8Hz
  1280x720 (0x55)   74.4MHz -HSync +VSync
        h: width  1280 start 1336 end 1472 total 1664 skew    0 clock   44.7KHz
        v: height  720 start  721 end  724 total  746           clock   60.0Hz
  1024x768 (0x4c)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0x4d)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  640x480 (0x56)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   60.0Hz

Peter
Comment 42 Jan 2012-06-18 01:41:09 UTC
Hi, 

I have same problem as described in this bug. I have laptop (HP ProBook 6360b) with DisplayPort video output (only external video output). Until Kernel 3.1, everything was working, but with Kernel 3.2 (and later), I can't use native resolution on my Fujitsu P23T-6 IPS monitor, which is 1920x1080. Interesting thing is, that I can use any other resolution on this monitor without problem (on Kernel 3.2 and later), just not the native one. I also have HP monitor at home, which have native resolution 1920x1200 and this monitor has no problem with latest kernels.

If I can provide some useful information, please tell me, which commands output you need.

Here I'm sending part of "xrandr --current --verbose" command. This is from Kernel 3.1.10-030110-generic #201201181135 (running on Ubuntu 12.04). Would info from Kernel 3.2 be helpful? 

DP3 connected 1920x1080+0+0 (0xd4) normal (normal left inverted right x axis y axis) 509mm x 286mm
        Identifier: 0x48
        Timestamp:  326240
        Subpixel:   unknown
        Gamma:      1.0:1.0:1.0
        Brightness: 1.0
        Clones:    
        CRTC:       0
        CRTCs:      1 0
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        EDID:
                00ffffffffffff001ab3e9071c010000
                2d140104a5331d783afe25a85337ae24
                115054a54b00a940b300950081008180
                010101010101023a801871382d40582c
                9600fd1e11000018000000fd00314c0f
                5211000a202020202020000000fc0050
                3233542d36204950530a2020000000ff
                00595633513030303238340a20200153
                020318744b909f859404130312010211
                2309070783010000023a80d072382d40
                102c9680fd1d11000018283c80a070b0
                234030203600fd1e1100001a011d00bc
                52d01e20b8285540fd1e1100001e011d
                007251d01e206e285500fd1e1100001e
                8c0ad090204031200c405500fd1e1100
                0018000000000000000000000000002a
        Broadcast RGB:  Full
                supported: Full         Limited 16:2
        audio:  off
                supported: off          auto         on          
  1920x1080 (0xd4)  148.5MHz -HSync -VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock   67.5KHz
        v: height 1080 start 1089 end 1095 total 1125           clock   60.0Hz
  1920x1200 (0xd5)  154.0MHz +HSync -VSync
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock   74.0KHz
        v: height 1200 start 1203 end 1209 total 1235           clock   60.0Hz
  1920x1080 (0xd6)  148.5MHz -HSync -VSync
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock   56.2KHz
        v: height 1080 start 1089 end 1095 total 1125           clock   50.0Hz
  1600x1200 (0xd7)  162.0MHz +HSync +VSync
        h: width  1600 start 1664 end 1856 total 2160 skew    0 clock   75.0KHz
        v: height 1200 start 1201 end 1204 total 1250           clock   60.0Hz
  1680x1050 (0xd8)  146.2MHz -HSync +VSync
        h: width  1680 start 1784 end 1960 total 2240 skew    0 clock   65.3KHz
        v: height 1050 start 1053 end 1059 total 1089           clock   60.0Hz
  1280x1024 (0xd9)  135.0MHz +HSync +VSync
        h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
  1280x1024 (0xda)  108.0MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1440x900 (0xdb)  106.5MHz -HSync +VSync
        h: width  1440 start 1520 end 1672 total 1904 skew    0 clock   55.9KHz
        v: height  900 start  903 end  909 total  934           clock   59.9Hz
  1280x800 (0xdc)   83.5MHz +HSync -VSync
        h: width  1280 start 1352 end 1480 total 1680 skew    0 clock   49.7KHz
        v: height  800 start  803 end  809 total  831           clock   59.8Hz
  1280x720 (0xdd)   74.2MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock   45.0KHz
        v: height  720 start  725 end  730 total  750           clock   60.0Hz
  1280x720 (0xde)   74.2MHz +HSync +VSync
        h: width  1280 start 1720 end 1760 total 1980 skew    0 clock   37.5KHz
        v: height  720 start  725 end  730 total  750           clock   50.0Hz
  1024x768 (0xdf)   78.8MHz +HSync +VSync
        h: width  1024 start 1040 end 1136 total 1312 skew    0 clock   60.1KHz
        v: height  768 start  769 end  772 total  800           clock   75.1Hz
  1024x768 (0x4c)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0xe0)   49.5MHz +HSync +VSync
        h: width   800 start  816 end  896 total 1056 skew    0 clock   46.9KHz
        v: height  600 start  601 end  604 total  625           clock   75.0Hz
  800x600 (0x4d)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  640x480 (0xe1)   31.5MHz -HSync -VSync
        h: width   640 start  656 end  720 total  840 skew    0 clock   37.5KHz
        v: height  480 start  481 end  484 total  500           clock   75.0Hz
  640x480 (0xe2)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   60.0Hz
  720x400 (0xe3)   28.3MHz -HSync +VSync
        h: width   720 start  738 end  846 total  900 skew    0 clock   31.5KHz
        v: height  400 start  412 end  414 total  449           clock   70.1Hz

Best regards,

Jan
Comment 43 Daniel Vetter 2012-06-18 02:04:11 UTC
Jan, can you please open a new report for your issue? I know, duplicate bugs are in most bugzillas frowned upon, but graphics bugs are rather hard to pinpoint, so I prefer to keep bugs separate until we have solid proof that they are duplicates. And similar symptoms are rather far from that.

Now to diagnose your issue, can you please try out the latest 3.5-rc kernel, boot with drm.debug=0xe and try out both the broken and the working monitor. Then please attach the full dmesg to your bug report (not this one here, otherwise we'll quickly have a chaos).
Comment 44 Jesse Barnes 2012-06-21 11:59:59 UTC
Created attachment 63320 [details] [review]
prefer many lanes and slow clocks to fast clocks with few lanes

This bug bugs me.  Can you try this crazy patch and see if it helps?  It might get you closer to your old config...
Comment 45 peter 2012-06-21 13:05:16 UTC
On Thu, Jun 21, 2012 at 11:59:59AM +0000, bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=45801
> 
> --- Comment #44 from Jesse Barnes <jbarnes@virtuousgeek.org> 2012-06-21 11:59:59 UTC ---
> Created attachment 63320 [details] [review]
>   --> https://bugs.freedesktop.org/attachment.cgi?id=63320
> prefer many lanes and slow clocks to fast clocks with few lanes
> 
> This bug bugs me.  Can you try this crazy patch and see if it helps?  It might
> get you closer to your old config...

Please see the attachment, I tested 3.4.0-rc3 with the patch applied,
and it works! With the crazy patch I get native resolution, even
after power cycling twice.

Thanks! Now the only thing missing is a sane commit message? :-)

Peter
Comment 46 peter 2012-06-21 13:05:17 UTC
Created attachment 63324 [details]
Linux 3.4.0-rc3 with patch "prefer many lanes and slow clocks to fast clocks with few lanes"
Comment 47 Jesse Barnes 2012-06-21 15:10:57 UTC
Oh great... my main worry about this patch is that it'll cause regressions with other configs.

But the theory is that cheap and/or long DP cables might not be able to transmit at high frequency well enough to sync and train the link.  Testing that theory is optional though, I think we can put this patch into -next and get a bunch of people banging on it.
Comment 48 peter 2012-06-21 15:22:56 UTC
On Thu, Jun 21, 2012 at 10:10:57PM +0000, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #47 from Jesse Barnes <jbarnes@virtuousgeek.org> 2012-06-21 15:10:57 PDT ---
> Oh great... my main worry about this patch is that it'll cause regressions with
> other configs.
> 
> But the theory is that cheap and/or long DP cables might not be able to
> transmit at high frequency well enough to sync and train the link.  Testing
> that theory is optional though, I think we can put this patch into -next and
> get a bunch of people banging on it.

The display is connected with an iCAN Premium DisplayPort 1080p cable, 3 m long.

In terms of price, it was certainly not cheap (13% of the price of the display).
Comment 49 Jesse Barnes 2012-06-21 15:30:21 UTC
Must just be the length then.  3m is a pretty long cable.  It's possible there's a vswing, preemphasis, and precharge that would make it work at high freq, but the lower frequency is probably better anyway.
Comment 50 Keith Packard 2012-06-21 17:15:51 UTC
so, there are two reasons to prefer fewer lanes:

 1) Lower power usage. Lighting up two lanes instead of four
    should reduce power usage, even running them at a higher data
Comment 51 Daniel Vetter 2012-07-04 00:43:05 UTC
I've merged Jesse's patch to drm-intel-next-queued as:

commit 684aaa646f90f5ee07799d52d0735625756e607b
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 21 15:13:50 2012 -0700

    drm/i915: prefer wide & slow to fast & narrow in DP configs
Comment 52 Florian Mickler 2012-08-05 11:24:29 UTC
A patch referencing this bug report has been merged in Linux v3.6-rc1:

commit 2514bc510d0c3aadcc5204056bb440fa36845147
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 21 15:13:50 2012 -0700

    drm/i915: prefer wide & slow to fast & narrow in DP configs