hda: Bug - (timing?) problem causes DP monitor to not get activated

hda: Bug - (timing?) problem causes DP monitor to not get activated

[Daniel Martin]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

Hi,

I'm having a bug here, where the loaded hda 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.

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 turn off into suspend state

Why I think that it is related to the hda module? 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 logs I have attached have been created on the T410 with kernel
v3.14-rc4. The first alsa-info....txt has been created right after
booting, the second one after step 4 failed. The kernel has been build
with all alsa debug options I could find, the config is attached as
well, and the kernel has been booted with drm.debug=0xe - this might be
to much, but it shows pretty clear when the outputs have been switched.

I hope that anyone can read something usefull - something that went
wrong - out of the log files. My unexercised eye can't spot anything
obvious.

If more logs are necessary, I'll send them.


Cheers,
    Daniel Martin

[-- Attachment #2: problem_with_dp_and_hda.tar.xz --]
[-- Type: application/x-xz, Size: 37584 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: hda: Bug - (timing?) problem causes DP monitor to not get activated

[Takashi Iwai]

At Fri, 28 Feb 2014 11:47:27 +0100,
Daniel Martin wrote:
> 
> Hi,
> 
> I'm having a bug here, where the loaded hda 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.
> 
> 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 turn off into suspend state
> 
> Why I think that it is related to the hda module? 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 logs I have attached have been created on the T410 with kernel
> v3.14-rc4. The first alsa-info....txt has been created right after
> booting, the second one after step 4 failed. The kernel has been build
> with all alsa debug options I could find, the config is attached as
> well, and the kernel has been booted with drm.debug=0xe - this might be
> to much, but it shows pretty clear when the outputs have been switched.
> 
> I hope that anyone can read something usefull - something that went
> wrong - out of the log files. My unexercised eye can't spot anything
> obvious.
> 
> If more logs are necessary, I'll send them.

Could you rather post it to intel-gfx ML?  (Please keep me in Cc.)

For IronLake, i915_request_power_well() must be irrelevant, thus it
can't be the HD-audio's runtime PM refcount.  There is no other direct 
communication with the graphics device, but only via HD-audio's
controller and codec; i.e. it's communicated via a normal hardware
channel.  If anything in the graphic output doesn't work in that
situation, the likely culprit is rather in the graphics side.


thanks,

Takashi