| Summary: | DP monitor does not get activated when snd_hda_intel is loaded | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Daniel Martin <consume.noise> | ||||
| Component: | DRM/Intel | Assignee: | Paulo Zanoni <przanoni> | ||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | intel-gfx-bugs, tiwai | ||||
| Version: | unspecified | ||||||
| Hardware: | Other | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
Something to try: xrandr --output DP1 --set audio off This will help determine if it is the background setup of the DP audio registers vs adjusting the DP link for enabling audio transfer. Is it a regression, i.e. did it ever work? I made a typo in my initial comment, it's DP2. Anyway ... (In reply to comment #2) > Is it a regression, i.e. did it ever work? (In reply to comment #1) > Something to try: > > xrandr --output DP1 --set audio off This didn't helped. Additionally, I disabled the audio property at every output having it (just to be sure) - didn't changed the result. > This will help determine if it is the background setup of the DP audio > registers vs adjusting the DP link for enabling audio transfer. (In reply to comment #2) > Is it a regression, i.e. did it ever work? Yes, it's a regression. Atm. I have tracked it down that the last working kernel was v3.6. Tomorrow, when being back at work, I'll test the last v3.6.x and then I'll try to bisect it. So, this took me a while (failed at bisecting etc.). One reason was the assumption that v3.6 is fine, which isn't true. Additionally, I made observations that help me to see from the dmesg if it's working or if the monitor will switch into suspend mode (more on this at the end).
I bisected it down to commit (v3.6-rc1):
2514bc5 drm/i915: prefer wide & slow to fast & narrow in DP configs
Reverting it on top of v3.6 fixes the problem. The used lanes drop and the clock raises from:
[drm:intel_dp_compute_config], DP link bw 06 lane count 4 clock 162000 bpp 24
to:
[drm:intel_dp_compute_config], DP link bw 0a lane count 2 clock 270000 bpp 24
But, that's the complete opposite why this commit/fix has been added:
https://bugs.freedesktop.org/show_bug.cgi?id=45801
So, reverting it may cause trouble at other maschines.
Then, I have switched to v3.14-rc5 for further testing:
1. Reverting 2514bc5 on top of v3.14-rc5 fixes the problem too. The next observatins have been done _without_ the revert - plain v3.14-rc5.
2. In my initial tests `xrandr --output DP2 --set audio off` didn't changed the result. Now, it works reliable. The problem is gone.
3. [drm:ilk_display_irq_handler], Pipe B FIFO underrun
If I see this message after a `xrandr --output DP2 --preferred`, while the audio property is at its default (auto), then I know that the monitor will switch on and everything is fine. If I don't see it, the monitor will switch into standby.
I hope that at least the last observation is helpful.
(In reply to comment #5) > I bisected it down to commit (v3.6-rc1): > 2514bc5 drm/i915: prefer wide & slow to fast & narrow in DP configs Please try drm-intel-nightly branch from http://cgit.freedesktop.org/drm-intel/ There's been some back and forth with this, and we've decided to prefer fast over wide again, which is according to DP spec. See http://mid.gmane.org/1393841890-15549-1-git-send-email-daniel.vetter@ffwll.ch Done, and I can confirm that the problem is gone with drm-intel-nightly (last commit id ccd4562). Fixed by commit 38aecea0ccbb909d635619cba22f1891e589b434 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 3 11:18:10 2014 +0100 drm/i915: reverse dp link param selection, prefer fast over wide again Thanks for the report and testing. FYI, I don't think we'll be backporting this to stable kernels, at least not before we've encountered and fixed all the fallout from this... |
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.
Created attachment 95024 [details] dmesg 3.14-rc4 @ Lenovo T410 (+alsa-debug options and drm.debug=0xe) I'm having a bug here, where the loaded hda (snd_hda_intel) module causes some (timing?) problem resulting in a monitor connected to the DP not to get active. I can reproduce this on a Lenovo X201 and T410 (Ironlake) sitting on a docking station, which has a monitor (Dell U2410) connected to a DP. First, I tried it on alsa-devel, but Takashi send me here. Steps to reproduce: 1. boot with the laptop at the docking station and the monitor plugged in 2. start the X-Server ... output on LVDS and DP is okay 3. disable the DP: xrandr --output LVDS1 --preferred --output DP1 --off ... output on LVDS - okay 4. switch to DP: xrandr --output LVDS1 --off --output DP1 --preferred ... DP _usually_ doesn't gets active, it turns off into suspend state If I boot a kernel _without_ the hda module step 4 always works. When having the hda module loaded I need some luck and some iterations of step 3 and 4 to activate the monitor at the DP. I verified that the problem exists in kernel v3.13.1 and v3.14-rc4. The dmesg I have attached has been created on the T410 with kernel v3.14-rc4 (enabled all alsa debug options I could find and booted with drm.debug=0xe). I didn't attached an X-server log, it didn't showed any errors. But, if requested I can create one with debug loggings enabled in xf86-video-intel (2.99.910 was in charge during the test(s)). Thanks in advance, Daniel Martin