Bug 40699 - KMS on Thinkpad W500: no picture on external monitors with DisplayPort, but DVI works.
Summary: KMS on Thinkpad W500: no picture on external monitors with DisplayPort, but D...
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2011-09-07 15:13 UTC by Andreas Wallberg
Modified: 2014-08-25 13:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

disable ss for DP on DCE3 (1.22 KB, patch)
2014-01-13 23:09 UTC, Alex Deucher
no flags Details | Splinter Review

Description Andreas Wallberg 2011-09-07 15:13:29 UTC
Hi all!

I have troubles connecting my Thinkpad W500 running Arch Linux 64-bit to external monitors via DisplayPort (DP) while using Kernel Mode Setting (KMS) and a recent kernel (3.0.4). KMS + DP appears to be broken. The laptop has a ATI Radeon HD 3650 chip.

I have tried two monitors: the HP ZR22w and the Eizo EV2333W.

HP ZR22w

When KMS+DP is used on boot, I get this error message on the HP ZR22w:

    Input signal Out of Range
    Change Settings to 1920 x 1080 - 60Hz

Inside X11, I am unable to get the screen going when KMS+DP is used. xrandr reports the screen being connected and that 1920x1080 is being sent to it. I still have the same error message.

If I turn off KMS, the monitor works just fine with DP and X11 and xrandr do their jobs but I obviously lose all the niceties with KMS.

If I use a DP->DVI adaptor and instead use the DVI connector on the monitor, KMS works just fine.

However, using the 2.6.35 kernel in Fedora 14, KMS + DP works just fine.

Eizo EV2333W

The same behavior as reported for the HP is true on the Eizo EV2333W monitor, but the latter provides more informative dialogs.

Using the old Fedora 2.6.35 kernel and KMS+DP, the monitor shows this info about the video signal on the Information dialog:

fH: 76.5kHz
fV: 59.9Hz

Using a 3.0.4 kernel in Arch and KMS+DP, the monitor shows:

Signal Error
fD: 111.1MHz
fH: 50.5kHz
fV: 44.8Hz

The "44.8" on the last line is read so there is obviously something wrong with the signal here.

My guess is that the EDID handling is broken somehow on DP. I have tried adding various video= switches in grub to force the resolution but I am not really sure how apply them to the DisplayPort (unable to find any documentation on this) or whether it matters since the problem seems to be that the kernel is unaware it sends an incorrect video signal to the monitor.

The only reference I have found to this monitor and KMS is this one, but I am not sure what to make of it: http://www.spinics.net/lists/dri-devel/msg13061.html

I would much appreciate any pointers! What logs and config files would you like to follow up on this?
Comment 1 Michel Dänzer 2011-09-08 01:47:48 UTC
(In reply to comment #1)
> However, using the 2.6.35 kernel in Fedora 14, KMS + DP works just fine.

Any chance you could bisect, or at least isolate the major kernel version where the problem was introduced?

Please attach the dmesg output, preferably from working and broken cases.
Comment 2 Maciej Pawlik 2014-01-13 21:31:55 UTC

I have the same issue on W500 and radeon hd3650 (or firegl v5700) RV635/M86 chip with dell u2412m monitor. Monitor complains that it cannot sync with signal from DP.
I was able to do a bisect of vanilla kernel, and this problem was introduced here:

git bisect start
# bad: [fb9a90f7c674f3ddef6baf55cb1612dadd8ea752] Merge remote branch 'airlied/drm-core-next' into tmp
git bisect bad fb9a90f7c674f3ddef6baf55cb1612dadd8ea752
# good: [42311ff90dc8746bd81427b2ed6efda9af791b77] drm/ttm: introduce utility function to free an allocated memory node
git bisect good 42311ff90dc8746bd81427b2ed6efda9af791b77
# good: [63847e66b28ed5e0dc28409d767e8f3891502ac4] Merge branch 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6
git bisect good 63847e66b28ed5e0dc28409d767e8f3891502ac4
# good: [53b2087d218c100657bddcb8ae887fa07862fb81] drm/i915: fix debugging compilation error from previous commit
git bisect good 53b2087d218c100657bddcb8ae887fa07862fb81
# good: [1bbee7d616d5fdffa6c1c86075dbffe2b3e236ea] Merge branch 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git bisect good 1bbee7d616d5fdffa6c1c86075dbffe2b3e236ea
# good: [96a03fce54af40b4f0820cd729608bc32c9b8949] Merge branch 'drm-kdb-next' into drm-core-next
git bisect good 96a03fce54af40b4f0820cd729608bc32c9b8949
# bad: [8088699f029b2a27af9bc5431ef7542c84195760] drm/i915: don't program FDI RX/TX in mode_set
git bisect bad 8088699f029b2a27af9bc5431ef7542c84195760
# bad: [e59f2bac15042eb744851bcf866f18dadc3091c6] drm/i915: Wait for pending flips on the GPU
git bisect bad e59f2bac15042eb744851bcf866f18dadc3091c6
# good: [f28488c282d8916b9b6190cc41714815bbaf97d5] drm/radeon/kms: remove some pll algo flags
git bisect good f28488c282d8916b9b6190cc41714815bbaf97d5
# bad: [75fa0b08e50cb72715b58321e8259c47adfe4c6f] drm/radeon: Modify radeon_pm_in_vbl to use radeon_get_crtc_scanoutpos()
git bisect bad 75fa0b08e50cb72715b58321e8259c47adfe4c6f
# bad: [ba032a58d1f320039e7850fb6e8651695c1aa571] drm/radeon/kms: rework spread spectrum handling
git bisect bad ba032a58d1f320039e7850fb6e8651695c1aa571
# good: [48dfaaeb6637240af3089bf9b7a00a6cf24e0182] drm/radeon/kms: remove new pll algo
git bisect good 48dfaaeb6637240af3089bf9b7a00a6cf24e0182
# first bad commit: [ba032a58d1f320039e7850fb6e8651695c1aa571] drm/radeon/kms: rework spread spectrum handling

So it's probably related to spread spectrum handling on displayport, which was introduced in that commit. I've done some tinkering with current kernel 3.12.6, and a simple change (this probably disables spread spectrum on DP) made my DP monitor work:

laptok linux # diff -ruN drivers/gpu/drm/radeon/atombios_crtc.c ~/atombios_crtc.c.original
--- drivers/gpu/drm/radeon/atombios_crtc.c      2014-01-13 21:46:29.000000000 +0100
+++ /root/atombios_crtc.c.original      2014-01-13 20:59:30.000000000 +0100
@@ -938,13 +938,11 @@
-                               } else {}
-                               /*
+                               } else
                                        radeon_crtc->ss_enabled =
-                                                                                */
                case ATOM_ENCODER_MODE_LVDS:

If there is anything more I can do please do let me know.
Comment 3 Maciej Pawlik 2014-01-13 21:34:15 UTC
Ooops, sorry the patch was made with incorrect order of arguments, and it turned out to be reversed. So add -R in mind when reading:)
Comment 4 Maciej Pawlik 2014-01-13 21:39:12 UTC
Oh, I don't know if this is useful but the monitor works in lowest resolution - 720x400 without any changes to current kernel.
Comment 5 Alex Deucher 2014-01-13 21:45:32 UTC
Does it work if you specify ATOM_DP_SS_ID2 rather than ATOM_DP_SS_ID1 in the problematic case?  What modes are you trying to use?
Comment 6 Maciej Pawlik 2014-01-13 23:06:32 UTC
I've done some testing, and vanilla kernel works only with 720x400. With ATOM_DP_SS_ID2, as you suggested, some modes work, some don't:
DisplayPort-0 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200      60.0 + <-ok
   1920x1080      60.0   <-ok
   1600x1200      60.0   <-ok
   1680x1050      60.0*  <-ok
   1280x1024      60.0   <-can't sync
   1280x960       60.0   <-can't sync
   1024x768       60.0   <-ok
   800x600        60.3   <-can't sync
   640x480        60.0   <-can't sync
   720x400        70.1   <-ok

It's the same with my crude fix.
Comment 7 Alex Deucher 2014-01-13 23:09:17 UTC
Created attachment 92007 [details] [review]
disable ss for DP on DCE3

Does disabling SS altogether help?  Try the attached patch.
Comment 8 Maciej Pawlik 2014-01-13 23:26:13 UTC
All modes work with the above patch.

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.