[alsa-devel] HD-audio runtime PM
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.
2. We don't change the device to D3 in runtime suspend. So I guess we save little power as of now.
Actually, setting to D3 and resuming to D0 works fine, as far as I tested -- except for HDMI/DP ELD read out on Haswell. Although ELD read doesn't give any errors, the received bytes are corrupted. In my case, the read starts from offset 0x1c.
The HDMI can be still played even at that state, but then it falls back to the stereo 2ch mode, of course.
The tests were performed on both Haswell (DP and LynxPoint-LP) and IvyBridge (PantherPoint) machines.
The first problem has been present, and it's also the behavior of some old chips where the codec can't go to sleep with unsol wakeup. So, in this regard, it's no regression, per se. But certainly it's no good thing.
I thought Mengdong once made WAKEEN working. Mengdong, do you remember what was the condition? Could you check whether the latest kernel (at best sound git tree for-linus branch) still works?
About the second point: we should do D3 if we do care power, and that's the very right reason for runtime PM. But the ELD issue is a bad bug, and it makes me wonder whether it's a graphics driver side issue or a codec side. As a quick workaround, we can implement D3 on controllers but for Haswell HDMI/DP.
In anyway, this is no urgent issue, clearly targeted for 3.14. The whole patch series are found in my sound-unstable git tree test/hda branch. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
thanks,
Takashi
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:
- 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".
And this is on 3.13-rc1, and there *shouldn't* be any Ubuntu specific stuff or configuration in that kernel.
Any ideas? (Sorry if this is a newbie question..)
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:
- 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"
Takashi
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:
- 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...)
I tried "echo auto > /sys/class/sound/card0/device/power/control" - after that, I had the following:
/sys/class/sound/card0/device/power/control - auto /sys/class/sound/card0/device/power/runtime_status - active /sys/class/sound/card0/power/control - auto /sys/class/sound/card0/power/runtime_status - unsupported
...so it did not seem to help.
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:
- 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.)
You can put a printk in azx_runtime_suspend(). For Haswell, it should work as is with 3.13-rc1.
For IvyBridge, check sound-unstable test/hda branch. I'll try to merge to sound git tree once after brushing up and submitting for review.
Takashi
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:
- 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?
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.)
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...
For IvyBridge, check sound-unstable test/hda branch. I'll try to merge to sound git tree once after brushing up and submitting for review.
Ok. I currently have nothing Ivybridge to check with.
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:
- 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.)
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?
Takashi
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.
Hi Takashi,
2013/11/22 Takashi Iwai tiwai@suse.de:
Hi,
after my previous fix, the runtime PM seems working stably finally. However, there seem still some glitches:
- 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.
- We don't change the device to D3 in runtime suspend. So I guess we
save little power as of now.
Actually, setting to D3 and resuming to D0 works fine, as far as I tested -- except for HDMI/DP ELD read out on Haswell. Although ELD read doesn't give any errors, the received bytes are corrupted. In my case, the read starts from offset 0x1c.
The HDMI can be still played even at that state, but then it falls back to the stereo 2ch mode, of course.
The tests were performed on both Haswell (DP and LynxPoint-LP) and IvyBridge (PantherPoint) machines.
The first problem has been present, and it's also the behavior of some old chips where the codec can't go to sleep with unsol wakeup. So, in this regard, it's no regression, per se. But certainly it's no good thing.
I thought Mengdong once made WAKEEN working. Mengdong, do you remember what was the condition? Could you check whether the latest kernel (at best sound git tree for-linus branch) still works?
About the second point: we should do D3 if we do care power, and that's the very right reason for runtime PM. But the ELD issue is a bad bug, and it makes me wonder whether it's a graphics driver side issue or a codec side. As a quick workaround, we can implement D3 on controllers but for Haswell HDMI/DP.
I didnot follow alsa-devel threads often now, is that ELD issue an regression from my previous commit? I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3. The controller must be in RESET mode after enter runtime-suspend, otherwise it will not be waken up even if codec send out wake-up event. And STATESTS will be cleared after controller brought out of RESET mode.
thanks --xingchao
In anyway, this is no urgent issue, clearly targeted for 3.14. The whole patch series are found in my sound-unstable git tree test/hda branch. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 26 Nov 2013 09:05:20 +0800, Wang Xingchao wrote:
Hi Takashi,
2013/11/22 Takashi Iwai tiwai@suse.de:
Hi,
after my previous fix, the runtime PM seems working stably finally. However, there seem still some glitches:
- 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.
- We don't change the device to D3 in runtime suspend. So I guess we
save little power as of now.
Actually, setting to D3 and resuming to D0 works fine, as far as I tested -- except for HDMI/DP ELD read out on Haswell. Although ELD read doesn't give any errors, the received bytes are corrupted. In my case, the read starts from offset 0x1c.
The HDMI can be still played even at that state, but then it falls back to the stereo 2ch mode, of course.
The tests were performed on both Haswell (DP and LynxPoint-LP) and IvyBridge (PantherPoint) machines.
The first problem has been present, and it's also the behavior of some old chips where the codec can't go to sleep with unsol wakeup. So, in this regard, it's no regression, per se. But certainly it's no good thing.
I thought Mengdong once made WAKEEN working. Mengdong, do you remember what was the condition? Could you check whether the latest kernel (at best sound git tree for-linus branch) still works?
About the second point: we should do D3 if we do care power, and that's the very right reason for runtime PM. But the ELD issue is a bad bug, and it makes me wonder whether it's a graphics driver side issue or a codec side. As a quick workaround, we can implement D3 on controllers but for Haswell HDMI/DP.
I didnot follow alsa-devel threads often now, is that ELD issue an regression from my previous commit?
I'm not sure whether it's a regression. We need to track down.
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
The controller must be in RESET mode after enter runtime-suspend, otherwise it will not be waken up even if codec send out wake-up event. And STATESTS will be cleared after controller brought out of RESET mode.
And I noticed that RESET mode makes some machines inconsistent, e.g. the mute LED is reset on HP machines without keeping the previous state. I need to double-check whether this still happens with the recent fixes.
thanks,
Takashi
thanks --xingchao
In anyway, this is no urgent issue, clearly targeted for 3.14. The whole patch series are found in my sound-unstable git tree test/hda branch. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
For non-Haswell platforms, hardware team suggest that unless all of the codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
Thanks Mengdong
The controller must be in RESET mode after enter runtime-suspend, otherwise it will not be waken up even if codec send out wake-up event. And STATESTS will be cleared after controller brought out of RESET mode.
And I noticed that RESET mode makes some machines inconsistent, e.g. the mute LED is reset on HP machines without keeping the previous state. I need to double-check whether this still happens with the recent fixes.
At Tue, 26 Nov 2013 06:56:12 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
For non-Haswell platforms, hardware team suggest that unless all of the codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
Is EPSS mandatory? We have already a check of ClkStopOK bit, but EPSS influences only on the wait time, so far.
Takashi
Thanks Mengdong
The controller must be in RESET mode after enter runtime-suspend, otherwise it will not be waken up even if codec send out wake-up event. And STATESTS will be cleared after controller brought out of RESET mode.
And I noticed that RESET mode makes some machines inconsistent, e.g. the mute LED is reset on HP machines without keeping the previous state. I need to double-check whether this still happens with the recent fixes.
At Tue, 26 Nov 2013 08:28:15 +0100, Takashi Iwai wrote:
At Tue, 26 Nov 2013 06:56:12 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
For non-Haswell platforms, hardware team suggest that unless all of the codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
Is EPSS mandatory? We have already a check of ClkStopOK bit, but EPSS influences only on the wait time, so far.
I forgot that EPSS check does exist for HDMI codecs. But it's not applied to other codecs.
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 4:26 PM
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A
controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
Hi,
I've checked two Haswell-ULT platforms with sound git tree for-linus branch, under Ubuntu: - ELD cannot refresh properly. - HDMI hot-plug cannot wake up the audio controller.
The controller is suspended when idle timeout and put in D3 by PCI driver. Here is the status shown by lspci -vvvv as root: 00:03.0 Audio device: Intel Corporation Device 0a0c (rev 09) Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- ... Status: D3 mean the device is in D3.
I guess maybe the latest display driver does not handle hot-plug properly which affect both ELD and device wakeup.
For Android on Haswell, the kernel code base and BIOS are different.
I'll further check this issue. Is it very urgent? I cannot work full time on this now due to some timing optimization task for Baytrail at the same time.
Regards Mengdong
At Wed, 27 Nov 2013 09:37:17 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 4:26 PM
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A
controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
Hi,
I've checked two Haswell-ULT platforms with sound git tree for-linus branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.
The controller is suspended when idle timeout and put in D3 by PCI driver. Here is the status shown by lspci -vvvv as root: 00:03.0 Audio device: Intel Corporation Device 0a0c (rev 09) Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- ... Status: D3 mean the device is in D3.
I guess maybe the latest display driver does not handle hot-plug properly which affect both ELD and device wakeup.
For Android on Haswell, the kernel code base and BIOS are different.
I'll further check this issue. Is it very urgent?
Not that urgent, but if it's a regression, we must fix it. If it's no regression, the urgency decreases, of course.
I cannot work full time on this now due to some timing optimization task for Baytrail at the same time.
At least, it'd be helpful if you can confirm whether it still works with vanilla 3.9.x kernel (or whatever version) you tested in the past -- i.e. to know whether it's a regression or not.
thanks,
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, November 27, 2013 6:55 PM To: Lin, Mengdong Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Wed, 27 Nov 2013 09:37:17 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 4:26 PM
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
> I test WAKEEN feature on Haswell machines before, it could > really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus
branch.
We've tried Android on Haswell-ULT last week, the display HD-A
controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
Hi,
I've checked two Haswell-ULT platforms with sound git tree for-linus
branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.
The controller is suspended when idle timeout and put in D3 by PCI
driver. Here is the status shown by lspci -vvvv as root:
00:03.0 Audio device: Intel Corporation Device 0a0c (rev 09) Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- ...Status:
D3 mean the device is in D3.
I guess maybe the latest display driver does not handle hot-plug
properly which affect both ELD and device wakeup.
For Android on Haswell, the kernel code base and BIOS are different.
I'll further check this issue. Is it very urgent?
Not that urgent, but if it's a regression, we must fix it. If it's no regression, the urgency decreases, of course.
I cannot work full time on this now due to some timing optimization
task for Baytrail at the same time.
At least, it'd be helpful if you can confirm whether it still works with vanilla 3.9.x kernel (or whatever version) you tested in the past -- i.e. to know whether it's a regression or not.
Okay, I'll try kernels close to when Xingchao enable this wake-up feature.
Thanks Mengdong
I've checked two Haswell-ULT platforms with sound git tree for-linus
branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.
I've tested the latest 3.13-rc2 based sound git tree, master branch: - ELD can refresh properly on hot-plug event. I need to bisect to see where the ELD regression happened and how it was fixed.
- Headset insertion can wake up the legacy audio controller (PCI device 00:1b)
- HDMI insertion still cannot wake up the display audio controller (PCI device 00:03) We'll double check with HW owner whether the display audio controller really supports wake up on HDMI/DP insertion. I remember when Xingchao enabled runtime PM on Haswell display audio controller for display power well release, there was an issue that this controller does not support "wake up", but we finally enable runtime PM on it and remove the request for "wake up".
Thanks Mengdong
I guess maybe the latest display driver does not handle hot-plug
properly which affect both ELD and device wakeup.
For Android on Haswell, the kernel code base and BIOS are different.
I'll further check this issue. Is it very urgent?
Not that urgent, but if it's a regression, we must fix it. If it's no regression, the urgency decreases, of course.
I cannot work full time on this now due to some timing optimization
task for Baytrail at the same time.
At least, it'd be helpful if you can confirm whether it still works with vanilla 3.9.x kernel (or whatever version) you tested in the past -- i.e. to know whether it's a regression or not.
Okay, I'll try kernels close to when Xingchao enable this wake-up feature.
Hi Takashi,
-----Original Message----- From: Lin, Mengdong Sent: Monday, December 09, 2013 3:03 PM
I've checked two Haswell-ULT platforms with sound git tree for-linus
branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.
I've tested the latest 3.13-rc2 based sound git tree, master branch:
- ELD can refresh properly on hot-plug event.
I need to bisect to see where the ELD regression happened and how it was fixed.
ELD info cannot refresh on hot-plug event after the controller enters D3 on Haswell. Sorry, I forgot to enable runtime PM yesterday when checking ELD refreshing.
- Headset insertion can wake up the legacy audio controller (PCI device
00:1b)
- HDMI insertion still cannot wake up the display audio controller (PCI
device 00:03) We'll double check with HW owner whether the display audio controller really supports wake up on HDMI/DP insertion. I remember when Xingchao enabled runtime PM on Haswell display audio controller for display power well release, there was an issue that this controller does not support "wake up", but we finally enable runtime PM on it and remove the request for "wake up".
HW team clarified that HDMI/DP jack insertion cannot wake up the controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot plug event even if the display power well is disabled. Although Gfx driver set Presence Detect and ELD Valid , the audio controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
Thanks Mengdong
At Tue, 10 Dec 2013 12:17:16 +0000, Lin, Mengdong wrote:
Hi Takashi,
-----Original Message----- From: Lin, Mengdong Sent: Monday, December 09, 2013 3:03 PM
I've checked two Haswell-ULT platforms with sound git tree for-linus
branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.
I've tested the latest 3.13-rc2 based sound git tree, master branch:
- ELD can refresh properly on hot-plug event.
I need to bisect to see where the ELD regression happened and how it was fixed.
ELD info cannot refresh on hot-plug event after the controller enters D3 on Haswell. Sorry, I forgot to enable runtime PM yesterday when checking ELD refreshing.
- Headset insertion can wake up the legacy audio controller (PCI device
00:1b)
- HDMI insertion still cannot wake up the display audio controller (PCI
device 00:03) We'll double check with HW owner whether the display audio controller really supports wake up on HDMI/DP insertion. I remember when Xingchao enabled runtime PM on Haswell display audio controller for display power well release, there was an issue that this controller does not support "wake up", but we finally enable runtime PM on it and remove the request for "wake up".
HW team clarified that HDMI/DP jack insertion cannot wake up the controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot plug event even if the display power well is disabled. Although Gfx driver set Presence Detect and ELD Valid , the audio controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 8:25 PM To: Lin, Mengdong Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Tue, 10 Dec 2013 12:17:16 +0000, Lin, Mengdong wrote:
Hi Takashi,
-----Original Message----- From: Lin, Mengdong Sent: Monday, December 09, 2013 3:03 PM
I've checked two Haswell-ULT platforms with sound git tree for-linus
branch, under Ubuntu:
- ELD cannot refresh properly.
- HDMI hot-plug cannot wake up the audio controller.
I've tested the latest 3.13-rc2 based sound git tree, master branch:
- ELD can refresh properly on hot-plug event.
I need to bisect to see where the ELD regression happened and how it was fixed.
ELD info cannot refresh on hot-plug event after the controller enters D3
on Haswell.
Sorry, I forgot to enable runtime PM yesterday when checking ELD
refreshing.
- Headset insertion can wake up the legacy audio controller (PCI
device 00:1b)
- HDMI insertion still cannot wake up the display audio controller
(PCI device 00:03) We'll double check with HW owner whether the display audio controller really supports wake up on HDMI/DP
insertion.
I remember when Xingchao enabled runtime PM on Haswell display audio controller for display power well release, there was an issue that this controller does not support "wake up", but we finally enable runtime PM on it and remove the request for "wake up".
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will wake up and audio driver can check ELD info.
Regards Mengdong
At Tue, 10 Dec 2013 12:34:51 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 8:25 PM To: Lin, Mengdong Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Tue, 10 Dec 2013 12:17:16 +0000, Lin, Mengdong wrote:
Hi Takashi,
-----Original Message----- From: Lin, Mengdong Sent: Monday, December 09, 2013 3:03 PM
> I've checked two Haswell-ULT platforms with sound git tree > for-linus branch, under Ubuntu: > - ELD cannot refresh properly. > - HDMI hot-plug cannot wake up the audio controller.
I've tested the latest 3.13-rc2 based sound git tree, master branch:
- ELD can refresh properly on hot-plug event.
I need to bisect to see where the ELD regression happened and how it was fixed.
ELD info cannot refresh on hot-plug event after the controller enters D3
on Haswell.
Sorry, I forgot to enable runtime PM yesterday when checking ELD
refreshing.
- Headset insertion can wake up the legacy audio controller (PCI
device 00:1b)
- HDMI insertion still cannot wake up the display audio controller
(PCI device 00:03) We'll double check with HW owner whether the display audio controller really supports wake up on HDMI/DP
insertion.
I remember when Xingchao enabled runtime PM on Haswell display audio controller for display power well release, there was an issue that this controller does not support "wake up", but we finally enable runtime PM on it and remove the request for "wake up".
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will wake up and audio driver can check ELD info.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 10:26 PM
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will wake
up and audio driver can check ELD info.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Hi Takashi,
I'm sure how to use a common object like vga_switcheroo. Would you please share more info?
I feel a wake up process may be like this: - Gfx driver detects the hot-plug at first and notify audio driver by the communication channel. - In the notification callback, the audio driver wakes up the audio controller to D0, but codec can still stay in D3. (Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event) - Then when Gfx driver enables or disables audio, and the audio controller can receive the unsol event in D0. - Audio driver check ELD in unsol event handler, this will make codec resume to D0.
Regards Mengdong
At Wed, 11 Dec 2013 05:37:44 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 10:26 PM
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will wake
up and audio driver can check ELD info.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Hi Takashi,
I'm sure how to use a common object like vga_switcheroo. Would you please share more info?
I feel a wake up process may be like this:
- Gfx driver detects the hot-plug at first and notify audio driver by the communication channel.
- In the notification callback, the audio driver wakes up the audio controller to D0, but codec can still stay in D3.
(Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event)
- Then when Gfx driver enables or disables audio, and the audio controller can receive the unsol event in D0.
- Audio driver check ELD in unsol event handler, this will make codec resume to D0.
If we have a direct communication with the graphics driver, the audio driver doesn't wait for the unsol event at all. It can retrieve ELD and even better port info more directly; i.e. we can skip even the wake up of the HDMI controller and codec chips. The notification and ELD updates can be done without the audio hardware, after all (actual ELD updates will be done at resume).
Takashi
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, December 11, 2013 9:37 PM To: Lin, Mengdong Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Wed, 11 Dec 2013 05:37:44 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 10:26 PM
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will
wake
up and audio driver can check ELD info.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Hi Takashi,
I'm sure how to use a common object like vga_switcheroo. Would you
please share more info?
I feel a wake up process may be like this:
- Gfx driver detects the hot-plug at first and notify audio driver by the
communication channel.
- In the notification callback, the audio driver wakes up the audio
controller to D0, but codec can still stay in D3.
(Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event)
- Then when Gfx driver enables or disables audio, and the audio
controller can receive the unsol event in D0.
- Audio driver check ELD in unsol event handler, this will make codec
resume to D0.
If we have a direct communication with the graphics driver, the audio driver doesn't wait for the unsol event at all. It can retrieve ELD and even better port info more directly; i.e. we can skip even the wake up of the HDMI controller and codec chips. The notification and ELD updates can be done without the audio hardware, after all (actual ELD updates will be done at resume).
Good idea. We can try this. The HDMI controller and codec can sleep until user space really wants to use HDMI audio.
Regards Mengdong
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Wednesday, December 11, 2013 9:37 PM To: Lin, Mengdong Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Wed, 11 Dec 2013 05:37:44 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 10:26 PM
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will
wake
up and audio driver can check ELD info.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Hi Takashi,
I'm sure how to use a common object like vga_switcheroo. Would you
please share more info?
I feel a wake up process may be like this:
- Gfx driver detects the hot-plug at first and notify audio driver by the
communication channel.
- In the notification callback, the audio driver wakes up the audio
controller to D0, but codec can still stay in D3.
(Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event)
- Then when Gfx driver enables or disables audio, and the audio
controller can receive the unsol event in D0.
- Audio driver check ELD in unsol event handler, this will make codec
resume to D0.
If we have a direct communication with the graphics driver, the audio driver doesn't wait for the unsol event at all. It can retrieve ELD and even better port info more directly; i.e. we can skip even the wake up of the HDMI controller and codec chips. The notification and ELD updates can be done without the audio hardware, after all (actual ELD updates will be done at resume).
For audio, using the SW communication interface to retrieve ELD information directly from gfx driver will be more reliable than using the verb.
Today we observed ELD corruption on Haswell after the audio controller resumes from D3 to D0. I removed and reconnect HDMI monitor when the controller is in D3. The gfx i195 driver will shut off the power well when HDMI monitor is removed and turn on power again when it detects HDMI is reconnected. But when I play something and thus resume the audio, ELD info shows monitor is present but ELD becomes invalid: The ELD info got by audio driver is corrupted and audio driver complains 'invalid ELD version 0'. It seems to be the ELD corruption issue you mention before.
We found the gfx driver still gets the proper ELD and uses it to update HW buffer for audio side. However, reading back shows the HW buffer is corrupted and update fails. So when theaudio driver uses verb to get ELD data, it also get the corrupted data.
If we force i915 to keeps its power well on (set i1915_disable_power_well = 0), there will be no ELD corruption. But we need to shut off power well if applicable for power saving.
So this adds one more reason to use a SW communication interface to retrieve the ELD info and other necessary info like port number.
Thanks Mengdong
-----Original Message----- From: Lin, Mengdong Sent: Wednesday, December 11, 2013 1:38 PM To: 'Takashi Iwai' Cc: Alsa-devel@alsa-project.org; Wang Xingchao; David Henningsson Subject: RE: [alsa-devel] HD-audio runtime PM
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, December 10, 2013 10:26 PM
HW team clarified that HDMI/DP jack insertion cannot wake up the
controller from D3. So this is a HW restriction for Haswell, not a driver regression.
Now the problem on Haswell/Broadwell is: After the controller enters D3, Gfx driver can still detect HDMI/DP hot
plug event even if the display power well is disabled.
Although Gfx driver set Presence Detect and ELD Valid , the audio
controller does not wake up and so audio driver has no idea about the HDMI/DP hot-plug.
Is it audio driver itself or the user space that need this ELD info? Maybe Gfx driver can directly report ELD info to user space.
If so, the graphics driver can wake up the audio driver as well -- this is yet one more reason to create a direct communication channel between the graphics and audio drivers :)
Need the audio driver provide an API for gfx driver? Maybe this API can call snd_hda_power_up(codec) and then snd_hda_power_down(codec), thus the controller and codec will wake
up and audio driver can check ELD info.
Well, we can create a common object containing the ops registered by both graphics and audio drivers, then communicate through it, something like vga_switcheroo.
Hi Takashi,
I'm sure how to use a common object like vga_switcheroo. Would you please share more info?
A typo here. I'm NOT sure how to use it.
I feel a wake up process may be like this:
- Gfx driver detects the hot-plug at first and notify audio driver by the
communication channel.
- In the notification callback, the audio driver wakes up the audio
controller to D0, but codec can still stay in D3. (Hope we can add a time out for controller here to avoid controller back to D3 at once and lose the capability to check unsol event)
- Then when Gfx driver enables or disables audio, and the audio controller
can receive the unsol event in D0.
- Audio driver check ELD in unsol event handler, this will make codec
resume to D0.
Regards Mengdong
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 3:28 PM To: Lin, Mengdong Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Tue, 26 Nov 2013 06:56:12 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A
controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
For non-Haswell platforms, hardware team suggest that unless all of the
codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
Is EPSS mandatory? We have already a check of ClkStopOK bit, but EPSS influences only on the wait time, so far.
It's a suggestion based on Windows experience. So maybe we can add this check at the moment. How do you think?
Regards Mengdong
At Tue, 26 Nov 2013 08:53:00 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 3:28 PM To: Lin, Mengdong Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Tue, 26 Nov 2013 06:56:12 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A
controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
For non-Haswell platforms, hardware team suggest that unless all of the
codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
Is EPSS mandatory? We have already a check of ClkStopOK bit, but EPSS influences only on the wait time, so far.
It's a suggestion based on Windows experience. So maybe we can add this check at the moment. How do you think?
Yes, it should be mostly harmless, as the recent codecs support already EPSS, and we enabled the runtime PM only on new controllers.
We can simply move the code in patch_hdmi.c to hda_codec.c.
Takashi
At Tue, 26 Nov 2013 09:56:00 +0100, Takashi Iwai wrote:
At Tue, 26 Nov 2013 08:53:00 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 3:28 PM To: Lin, Mengdong Cc: Wang Xingchao; Alsa-devel@alsa-project.org; David Henningsson Subject: Re: [alsa-devel] HD-audio runtime PM
At Tue, 26 Nov 2013 06:56:12 +0000, Lin, Mengdong wrote:
-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 2:14 PM To: Wang Xingchao
I test WAKEEN feature on Haswell machines before, it could really wakeup system from D3.
But the runtime suspend doesn't power down to D3 by itself. Did you test really with D3?
I will double check this on Haswell with sound git tree for-linus branch. We've tried Android on Haswell-ULT last week, the display HD-A
controller can enter D3 and HDMI cable plug-in can wake up the controller and codec. The code base is v3.9 with various driver patches.
Hrm, but as I mentioned, we have no D3 call in runtime suspend callback. How does it reach to D3 then? Maybe that part is patched in your side?
For non-Haswell platforms, hardware team suggest that unless all of the
codecs on the HD-A link support EPSS and ClkStopOK, runtime PM of the controller should not be enabled on the controller. Otherwise, functionality will be lost and there are likely going to be audio artifacts.
Is EPSS mandatory? We have already a check of ClkStopOK bit, but EPSS influences only on the wait time, so far.
It's a suggestion based on Windows experience. So maybe we can add this check at the moment. How do you think?
Yes, it should be mostly harmless, as the recent codecs support already EPSS, and we enabled the runtime PM only on new controllers.
We can simply move the code in patch_hdmi.c to hda_codec.c.
That is, a patch like below. This was queued to test/hda branch of sound-unstable git tree.
Takashi
-- >8 -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable runtime PM when EPSS is unavailable
According to Mengdong, we shouldn't enable runtime PM when a codec doesn't support EPSS, based on the experiences on Windows. We have already this check in HDMI codec drivers, but now apply it in general in hda_codec.c.
Credit goes to Mengdong Lin mengdong.lin@intel.com
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_codec.c | 7 +++++-- sound/pci/hda/patch_hdmi.c | 11 ----------- 2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 8f7295bdccbd..6deb8d1852cc 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1510,11 +1510,14 @@ int snd_hda_codec_new(struct hda_bus *bus, #ifdef CONFIG_PM codec->d3_stop_clk = snd_hda_codec_get_supported_ps(codec, fg, AC_PWRST_CLKSTOP); - if (!codec->d3_stop_clk) - bus->power_keep_link_on = 1; #endif codec->epss = snd_hda_codec_get_supported_ps(codec, fg, AC_PWRST_EPSS); +#ifdef CONFIG_PM + if (!codec->d3_stop_clk || !codec->epss) + bus->power_keep_link_on = 1; +#endif +
/* power-up all before initialization */ hda_set_power_state(codec, AC_PWRST_D0); diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 1773a640e72e..4098196b2300 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1692,17 +1692,6 @@ static int hdmi_parse_codec(struct hda_codec *codec) } }
-#ifdef CONFIG_PM - /* - * G45/IbexPeak don't support EPSS: the unsolicited pin hot plug event - * can be lost and presence sense verb will become inaccurate if the - * HDA link is powered off at hot plug or hw initialization time. - */ - if (!(snd_hda_param_read(codec, codec->afg, AC_PAR_POWER_STATE) & - AC_PWRST_EPSS)) - codec->bus->power_keep_link_on = 1; -#endif - return 0; }
participants (4)
-
David Henningsson -
Lin, Mengdong -
Takashi Iwai -
Wang Xingchao