[alsa-devel] HD-audio runtime PM

[David Henningsson]

On 11/25/2013 11:34 AM, Takashi Iwai wrote:
> At Mon, 25 Nov 2013 11:25:46 +0100,
> David Henningsson wrote:
>>
>> On 11/25/2013 10:26 AM, Takashi Iwai wrote:
>>> At Mon, 25 Nov 2013 10:20:55 +0100,
>>> David Henningsson wrote:
>>>>
>>>> On 11/25/2013 08:17 AM, Takashi Iwai wrote:
>>>>> At Mon, 25 Nov 2013 07:32:57 +0100,
>>>>> David Henningsson wrote:
>>>>>>
>>>>>> On 11/22/2013 12:57 PM, Takashi Iwai wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> after my previous fix, the runtime PM seems working stably finally.
>>>>>>> However, there seem still some glitches:
>>>>>>>
>>>>>>> 1. The wakeup via jack or HDMI/DP detection doesn't seem to work on my
>>>>>>>   test machines.  WAKEEN is set properly.  And its value can be read
>>>>>>>   correctly at the point of runtime resume, too.
>>>>>>
>>>>>> Hi and thanks for working on this.
>>>>>>
>>>>>> I've been trying to reproduce the above, but I can't seem to activate
>>>>>> runtime PM at all. I can't seem to get a callback to runtime_suspend,
>>>>>> and further investigation shows that
>>>>>> /sys/class/sound/card0/power/runtime_status shows "unsupported".
>>>>>
>>>>> You need to adjust power/control of the parent PCM device,
>>>>> i.e. /sys/devices/pci/*/power/control.  The following udev rule should
>>>>> work for HD-audio.  Give it a try.
>>>>>
>>>>>   ACTION=="add", SUBSYSTEM=="pci", ATTR{class}=="0x040300", TEST=="power/control", ATTR{power/control}="auto"
>>>>
>>>> I tried this rule, but it did not make any difference -
>>>> /sys/class/sound/card0/device/power/control was still on. (And I did
>>>> proofread the rule...)
>>>
>>> This (and other sound/*) doesn't matter.  Only the entry in the PCI
>>> device counts.  It's the runtime PM of the PCI device after all.
>>> (Remember that the runtime PM callbacks are set only on this device.)
>>
>> But /sys/class/sound/card0/device is just a symlink for
>> /sys/devices/pci0000:00/0000:00:03.0 - is this not the PCI device you're
>> talking about?
> 
> Ah, ok, I missed ..../device/... part.  Then it's correct.
> If it doesn't change, it means that the udev rule isn't correctly
> installed or activated by some reason.  You can check the udev log, or
> just check via udevadm monitor and udevadm trigger.  For a temporary
> testing, you can of course change the sysfs entry manually...
> 
>> Anyway, power/runtime_status is always active, and power/usage_count is
>> always 1. (And pulseaudio is not running, and nothing else is using any
>> /dev/snd/* files.)

Found it. It was the power_save module parameter that kept a usage_count
on the device. Sorry for the noise.

Anyway; I could then reproduce the bug (noticed by missing ELD update on
plug/unplug of HDMI monitor). I also went back to the WAKEEN commit
(originally by Xingchao), but it didn't work there either. The
interrupts do not get through. (Feel free to double check.)

>>> You can put a printk in azx_runtime_suspend().  For Haswell, it should
>>> work as is with 3.13-rc1.
>>
>> I guess I could test that, but I doubt it would help...
> 
> You're testing with Haswell and 3.13-rc1, right?

Right.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic