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.