Bug 78507 - [hsw dp]No native resolution 2560x1600 on Lenovo Onelink Pro DisplayPort and X1 Carbon 2014
Summary: [hsw dp]No native resolution 2560x1600 on Lenovo Onelink Pro DisplayPort and ...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Daniel Vetter
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-09 23:10 UTC by Chunlei Wu
Modified: 2017-07-24 22:54 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg_debug_DP2.txt (133.59 KB, text/plain)
2014-05-09 23:10 UTC, Chunlei Wu
no flags Details
dmesg_debug_patched.txt (177.90 KB, text/plain)
2014-05-13 18:27 UTC, Chunlei Wu
no flags Details
20140812_dmesg_debug_DP2.txt (113.74 KB, text/plain)
2014-08-12 20:35 UTC, Chunlei Wu
no flags Details
20140812_xrandr.txt (8.71 KB, text/plain)
2014-08-12 20:36 UTC, Chunlei Wu
no flags Details
20140907_dkms_i915_make.log (81.42 KB, text/plain)
2014-09-08 16:52 UTC, Chunlei Wu
no flags Details
20140908_dmesg_debug_DP2_3.17rc4.log (141.07 KB, text/plain)
2014-09-08 16:53 UTC, Chunlei Wu
no flags Details
20141218_dmesg_debug_3.18_drm-intel-nightly.txt (251.84 KB, text/plain)
2014-12-18 18:14 UTC, Chunlei Wu
no flags Details
20141218_xrandr.txt (14.30 KB, text/plain)
2014-12-18 18:33 UTC, Chunlei Wu
no flags Details

Description Chunlei Wu 2014-05-09 23:10:57 UTC
Created attachment 98791 [details]
dmesg_debug_DP2.txt

Previous drm-intel-nightly kernel (http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-04-17-trusty/) solves the native resolution issue, but caused blank screen on built-in laptop display. See bug 77660.

The latest drm-intel-nightly kernel (3.15.0-994_3.15.0-994.201405080316) solves the blank screen issue now, but I lose the native resolution 2560x1600 on external display. It only support generic 1024x768 and 800x600 modes. 

I can see many errors like this in dmesg log:

[    6.433670] [drm:drm_dp_i2c_do_msg] I2C defer
[    6.434177] [drm:drm_dp_i2c_do_msg] too many retries, giving up

I attached full dmesg log with drm.debug=0xe.

It's very tricky that, occasionally, it does work fine, but most of time, it's not. I tried booting into Windows 8, it never had the issue.


System environment:
-- chipset: intel i7-4600U (HD-4400)
-- system architecture: 64-bit
-- kernel: drm-intel-nightly kernel (3.15.0-994_3.15.0-994.201405080316)
-- Linux distribution: Ubuntu 14.04
-- xserver: 1.15.1
-- xserver-xorg-video-intel: 2:2.99.910-0ubuntu1 
-- Machine or mobo model: Lenovo X1 Carbon 2014 (20A7CTO1WW)
-- Display connector: DisplayPort on OneLink Pro dock
-- Monitor: Dell U3011

Reproducing steps:
* install latest drm-intel-nightly upstream kernel
* boot with this kernel
Comment 1 Chunlei Wu 2014-05-09 23:12:33 UTC
bug 74266 is relevant.
Comment 2 Jani Nikula 2014-05-12 06:52:54 UTC
Please try this hack patch on top of nightly:

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a13f1f51f68e..2020619e2b98 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -591,7 +591,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
         * is required to retry at least seven times upon receiving AUX_DEFER
         * before giving up the AUX transaction.
         */
-       for (retry = 0; retry < 7; retry++) {
+       for (retry = 0; retry < 50; retry++) {
                err = aux->transfer(aux, msg);
                if (err < 0) {
                        if (err == -EBUSY)
@@ -649,7 +649,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
 
                case DP_AUX_I2C_REPLY_DEFER:
                        DRM_DEBUG_KMS("I2C defer\n");
-                       usleep_range(400, 500);
+                       usleep_range(1400, 1500);
                        continue;
 
                default:
Comment 3 Chunlei Wu 2014-05-12 16:40:43 UTC
Thanks. Can you point me to the instruction on how to apply this patch? Never done that before.
Comment 4 Chunlei Wu 2014-05-13 00:48:56 UTC
I found this is useful for building upstream kernel from the source:

https://wiki.ubuntu.com/KernelTeam/GitKernelBuild

working on it...
Comment 5 Chunlei Wu 2014-05-13 18:27:47 UTC
Created attachment 98991 [details]
dmesg_debug_patched.txt

Patch applied on drm-intel-nightly (18a7661946082f5a3b353e50d1ced5d89f864024). But still the same problem. dmesg_debug_patched.txt attached.
Comment 6 Chunlei Wu 2014-05-13 20:48:59 UTC
Worth mentioning that when default 14.04 kernel (3.13.0-24) is used, I was able to get 1920x1440 resolution (still not native 2560x1600 though).
Comment 7 Chunlei Wu 2014-08-12 20:34:58 UTC
I'm now using linux kernel 3.13.0-33-generic (latest from Ubuntu trusty updates). The issue is still there: no native resolution on the dock DP output (DP2). It falls back to 1024x768. While the min-DP port on the laptop is always working (DP1).

I will attach updated dmesg_debug output and xrandr output shortly. Can someone help debug this issue? I can provide any further debug info and test the patches.
Comment 8 Chunlei Wu 2014-08-12 20:35:55 UTC
Created attachment 104525 [details]
20140812_dmesg_debug_DP2.txt
Comment 9 Chunlei Wu 2014-08-12 20:36:20 UTC
Created attachment 104526 [details]
20140812_xrandr.txt
Comment 10 Jani Nikula 2014-09-05 13:35:14 UTC
Please try v3.16 or later.
Comment 11 Chunlei Wu 2014-09-08 16:52:18 UTC
Created attachment 105898 [details]
20140907_dkms_i915_make.log

Hello,

I have tried the latest v3.17rc4 upstream kernels from http://kernel.ubuntu.com/~kernel-ppa/mainline/ (under v3.17-rc4-utopic folder, "3.17.0-031700rc4_3.17.0-031700rc4.201409071935")

during the installation, I got multiple errors like this:

>Error! Bad return status for module build on kernel: 3.17.0-031700rc4-generic (x86_64)
>Consult /var/lib/dkms/i915-3.15-3.13/0.01/build/make.log for more information.
>Error! Bad return status for module build on kernel: 3.17.0-031700rc4-generic (x86_64)
>Consult /var/lib/dkms/virtualbox/4.3.10/build/make.log for more information.

See attached 20140907_dkms_i915_make.log file. 

Despite the erros, installation went through, and I can reboot OK without OneLink Pro connected. However, if I boot with OneLink Pro connected, I cannot boot into my normal gdm login screen, it goes to terminal directly. See attached 20140908_dmesg_debug_DP2_3.17rc4.log .

I also tried the latest kernels from drm-intel-daily and drm-intel-next, I got the same results.

drm-intel-daily/3.17.0-994_3.17.0-994.201409042205d 
drm-intel-next/3.16.0-997_3.16.0-997.201408270257


Anything else I can help to debug this issue? Thanks.
Comment 12 Chunlei Wu 2014-09-08 16:53:02 UTC
Created attachment 105899 [details]
20140908_dmesg_debug_DP2_3.17rc4.log
Comment 13 Jesse Barnes 2014-12-05 18:59:38 UTC
The native resolution is being detected, and presumably the console is coming up in the full mode, so the X failure may be related to the installation problems you saw.

Have you since installed a newer kernel?  If so, do things work now?
Comment 14 Chunlei Wu 2014-12-18 18:13:46 UTC
I have just tried the latest drm-intel-nightly kernel:

linux-headers-3.18.0-994_3.18.0-994.201412180253_all.deb
linux-headers-3.18.0-994-generic_3.18.0-994.201412180253_amd64.deb
linux-image-3.18.0-994-generic_3.18.0-994.201412180253_amd64.deb


And confirmed that I can get 2560x1600 native resolution now. That's awesome!
Comment 15 Chunlei Wu 2014-12-18 18:14:27 UTC
Created attachment 110998 [details]
20141218_dmesg_debug_3.18_drm-intel-nightly.txt
Comment 16 Chunlei Wu 2014-12-18 18:33:14 UTC
Created attachment 111002 [details]
20141218_xrandr.txt

2560x1600 native resolution was recognized correctly now.

I also noticed that now the display port on Lenovo Onelink Pro is designated as DP4 (previously as DP2).
Comment 17 Jani Nikula 2014-12-19 08:53:05 UTC
Thanks for the report and testing. Please reopen if the problem persists.


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.