Hi! So here's another weird one... With 3.14.x, I was struggling with my Latitude E5440's docker's display port output: it wouldn't switch on the connected monitor for at least a minute (after turning it on, or waking the laptop up from sleep). Switching to 3.15 solved this, I was very happy: the monitor switching was snappy - almost instant - after waking the computer up from sleep. The last good version for me was 3.15.6, and now with 3.15.7, the display port got slow again. Admittingly, not *as* slow as with 3.14, but much slower than 3.15.0 <= 3.15.6. I don't even know if this is a power management issue, to be honest. Is this something you guys would be concerned with? -- Daniel
It's the same with 3.15.8.
It's much more worse with 3.16-rc7. It goes back to 3.14-era, and never seems to turn on the displayport monitor.
Could you do a bisect between v3.15 and v3.16-rc6 to find which commit makes it worse? This seems not related with PM and so reassign to video component.
Sure thing. It seems that the offending commit was: commit 1c46b5d7cd5d9912687a9e65626cdc24b1074ae1 Author: Dave Airlie <airlied@redhat.com> Date: Mon Jul 14 11:04:39 2014 +1000 Revert "drm/i915: reverse dp link param selection, prefer fast over wide again" If I checkout 3.15.8 and revert this one commit, then the external monitor detection/switching on the display port is fast again. The original commit between 3.15-rc5 and rc6, which was revert by the above one, was: commit f4cdbc21444a45d207a8dc175f44d2facfbd0845 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed May 14 13:02:19 2014 +0300 drm/i915/dp: force eDP lane count to max available lanes on BDW -- Daniel
Oh, but I just realized that I read what I wanted to read :) So, I did the bisect between 3.15.6 and 3.15.7, I never went to 3.16. Is this okay anyways? -- Daniel
Sorry, the original commit was not that, it was just referenced by that one... Anyway, I know it's not my job to tell you guys these, so I'll just shut up and wait for the fix (he-he) ;-> -- Daniel
Anything else I can help you guys with to fix this? Don't drop the ball...
Please try drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel, and attach full dmesg from boot to the problem with drm.debug=0xe module parameter set.
Nevermind; I had stopped using this hardware as its support gets worse with every kernel release.