Bug 72314

Summary: [hsw] Enabling ext. Monitor takes up to 24s
Product: DRI Reporter: Daniel Martin <consume.noise>
Component: DRM/IntelAssignee: Jani Nikula <jani.nikula>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: lowest CC: akaburtan, cordlandwehr, intel-gfx-bugs, pprasse
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on: 71267    
Bug Blocks:    
Attachments:
Description Flags
dmesg 3.13.0-rc1 replug monitor 5 times
none
dmesg 3.13.0-rc1 boot with monitor plugged in none

Description Daniel Martin 2013-12-04 14:12:15 UTC 
Created attachment 90237 [details]
dmesg 3.13.0-rc1 replug monitor 5 times

+++ This bug was initially created as a clone of Bug #71267 +++

- same HW as in bug #71267
- kernel v3.13.0-rc1 + udelay(500) (see bug #71267, comment #29 and comment #32)

(As stated in the initial bug udelay() has to be raised to 500. Todd wrote that 300 might be okay. So, 500 is far above this. Hopefully the 500 doesn't cause this bug as a side-effect.)

When plugging in the monitor at one DP of the docking station it takes up to 24s (shortest was 3s) until it gets activated (the console cloned to it).
In this attachment I've replugged the monitor 5 times, log timestamps are:
  1. 30-33 ... 3s
  2. 74-85 ... 11s
  3. 184-203 ... 19s
  4. 238-262 ... 24s
  5. 303-310 ... 7s

As of this I wouldn't call it a bug - the monitor gets activated finally. Therefor I've set the priority to "lowest".
Comment 1 Daniel Martin 2013-12-04 14:14:50 UTC 
Created attachment 90238 [details]
dmesg 3.13.0-rc1 boot with monitor plugged in

But, such delays happen when booting with the monitor already been plugged in too. Here the effect is that the internal laptop display turns "blank" (with one small sprinkled blue line) until the external monitor gets activated.

The delay can be seen in this attachment.
Comment 2 Jani Nikula 2013-12-05 09:07:02 UTC 
Note: this is about native aux defer, and the delay in retry.
Comment 3 Chris Wilson 2014-02-12 19:45:12 UTC 
What's the outcome of http://cgit.freedesktop.org/~jani/drm/log/?h=native-aux-defer-v3.13.2 ? In particular, does the cap on the number of retries prevent us from enabling the monitor?
Comment 4 Daniel Martin 2014-02-20 10:49:55 UTC 
(Sorry, for not reporting earlier. First the laptop was occupied by a colleague, then I've forgotten this bug.)

I can't reproduce this issue with Janis native-aux-defer patches anymore. The monitor turns on within a few seconds. I've replugged it round about 10 times. Therefore, I'm closing this bug.

Thanks.
Comment 5 Jani Nikula 2014-02-24 09:04:49 UTC 
(In reply to comment #4)
> I can't reproduce this issue with Janis native-aux-defer patches anymore.
> The monitor turns on within a few seconds. I've replugged it round about 10
> times. Therefore, I'm closing this bug.

Thanks for verifying this.
Comment 6 Daniel Vetter 2014-03-03 10:20:31 UTC 
Is this really resolved in upstream already or only in Jani's patches? Please test the latest drm-intel-nightly from http://cgit.freedesktop.org/drm-intel

Please don't close a bug report just because there's a working patch, we'll forget about it otherwise ...
Comment 7 Jani Nikula 2014-03-03 10:33:00 UTC 
(In reply to comment #6)
> Is this really resolved in upstream already or only in Jani's patches?

v3.14-rc4 has them:

commit f51a44b9a6c4982cc25bfb3727de9bb893621ebc
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Feb 11 11:52:05 2014 +0200

    drm/i915/dp: add native aux defer retry limit

commit 04eada25d1f72efdecd32d702706594f81de65d5
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue Feb 11 11:52:04 2014 +0200

    drm/i915/dp: increase native aux defer retry timeout

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.