Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Takashi, In order to let audio power-save work even with charger connected, two parameters need be modified in userspace pm-utils scripts. I tested the changes under Ubuntu 13.10 on Harris Beach, no matter charger connected or not, runtime power-saving works and power-well will Be released as expected. Here's my test under Ubuntu 13.04, the changes are: 1) /usr/lib/pm-utils/power.d/intel-audio-powersave case $1 in true) audio_powersave 1 ;; +false) audio_powersave 10 ;; -false) audio_powersave 0 ;; help) help;; *) exit $NA esac Audio will enter power-save mode after 10s inactive period. 2) /usr/lib/pm-utils/power.d/pci_devices 0x040300) # audio echo Setting Audio device $id to $1 + echo auto $dev/power/control -echo $1 $dev/power/control This keep audio subsystem always on. This way the user may not let audio subsystem always active, may bring some delay from codec/controllers, or harm some chips. Do you think we should add an exception for Haswell only or just make it as a common solution for audio subsystem? Thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Wednesday, July 24, 2013 10:00 PM To: Takashi Iwai Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio -p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. Oh yes I found the hook: ./pm/power.d/intel-audio-powersave --xingchao The former is unknown, but better to check pm-utils hooks and udev rules. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Paulo, Would you help verify attached patch to fix this issue for you? The patch is based on Takashi's tree, the last commit is: commit 9b298cfe296c0f8e088b9ed9a670783a06005e6b I think it should be safe to merge into your tree. :) I tested the patch on Harris Beach, it would let audio driver release power-well even with charger connected. Please note maybe this is not the final solution for this issue as it breaks some rule from user's point of view. Some background of this issue: This patch intended to fix power-well regression on Haswell. On Harris Beach(Ultrabook with battery), there's only eDP panel connected by default, no HDMI/DP. And gfx driver needs enable some HW feature for eDP, power-well *must* be disabled in this scenario. - Witout charger connected, power-well feature is perfect - with charger connected, audio never release power-well. Basically, power-well should be release if audio driver doesnot use it, that's why we enabled runtime power-save feature. In second case above, with charger connected, the parameter under /sys/devices/../power/control become on always. In audio driver side, power_save was set to 0, which disable power_down the codecs and controller, thus never release power-usage_count. And this blocks audio driver release power-well. In the second case, if audio driver detect hdmi pins are free and no Apps opened device, it will eanble runtime power-save feature as an exception. I test this patch on Harris beach with charger connected, the power-well could be released as expected. Thanks --xingchao -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Thursday, July 18, 2013 5:35 PM To: Wang, Xingchao Cc: Daniel Vetter; Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Thu, 18 Jul 2013 09:23:57 +, Wang, Xingchao wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, July 18, 2013 2:44 PM To: Wang, Xingchao Cc: Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; Takashi Iwai; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote: Hi Paulo/Daniel, Do you agree to export an API in gfx side for eDP case? Basically the api will let audio drver know which pipe in use. i.e. in the eDP only caes, audio driver Will know gfx is not using HDMI/DP and would like to let power-well off. As there's the conflict when user expect display audio driver always active but gfx need audio driver off. Audio driver could make decision to release power-well if it knows the eDP only case through the API. OTOH, I think audio driver could also export an API for gfx side, if gfx driver need audio driver release power-well but it's in usage, It will call this API and audio drvier will release power-well accordingly. This change make HDMI/DP hotplug handling complicated in audio driver side, if audio driver release power-well, it would enter suspend mode. Meanwhile the user may expect it's in active mode, this may cause some confuse. Afaik (and I know very little about audio) the audio side already knows which pipes have audio enabled, since we set the respective bit only when it's needed. And audio will receive the unsolicited even interrupt (or whatever it's called) when this happens. For haswell, Audio driver can get DDI port/Pin usage information according to the unsolicited event, not Pipe info. However at this stage, seems only that is enough: if no pin has valid ELD, audio driver can think about that no monitor connected with DDI ports. In this case, Audio driver could release power-well and enter suspend mode automatically, this avoid blocking eDP feature enabling. And once gfx dirver Detect external monitor connected, it will also wake up audio driver. Takashi, do you think this solution acceptable? It's the current situation, isn't it? So the question is only whether this works _as expected_. Basically system/user needs to set up two parameters for the audio power-saving. If both are set well, but it still doesn't work, we need to debug. Of course, we can improve things, for example, the default runtime PM setup. (Note that this is about the default value, not the value force to set.) Takashi Thanks --xingchao So I think we already have the means (albeit with that quirky hw interface, but it seems to have been good enough
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Wed, 24 Jul 2013 10:31:22 +, Wang, Xingchao wrote: Hi Paulo, Would you help verify attached patch to fix this issue for you? The patch is based on Takashi's tree, the last commit is: commit 9b298cfe296c0f8e088b9ed9a670783a06005e6b I think it should be safe to merge into your tree. :) I tested the patch on Harris Beach, it would let audio driver release power-well even with charger connected. Please note maybe this is not the final solution for this issue as it breaks some rule from user's point of view. Well, this patch is NACK from my side. Sorry, but this is a wrong approach. Some background of this issue: This patch intended to fix power-well regression on Haswell. On Harris Beach(Ultrabook with battery), there's only eDP panel connected by default, no HDMI/DP. And gfx driver needs enable some HW feature for eDP, power-well *must* be disabled in this scenario. - Witout charger connected, power-well feature is perfect - with charger connected, audio never release power-well. Basically, power-well should be release if audio driver doesnot use it, that's why we enabled runtime power-save feature. In second case above, with charger connected, the parameter under /sys/devices/../power/control become on always. Why this is set to on *always*, even if the device can be actually controlled via runtime PM? In audio driver side, power_save was set to 0, which disable power_down the codecs and controller, thus never release power-usage_count. Why it is set to zero at all? And this blocks audio driver release power-well. In the second case, if audio driver detect hdmi pins are free and no Apps opened device, it will eanble runtime power-save feature as an exception. I test this patch on Harris beach with charger connected, the power-well could be released as expected. The primary problem is that these flags are set. You're trying to implement an ignore stop-signs on the street if no other cars are running around you feature in a new auto-cruise system. It would work, but it's not what's accepted in general. (And it makes things complicated and fragile.) The real question is why there are two useless STOP signs there. thanks, Takashi Thanks --xingchao -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Thursday, July 18, 2013 5:35 PM To: Wang, Xingchao Cc: Daniel Vetter; Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Thu, 18 Jul 2013 09:23:57 +, Wang, Xingchao wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, July 18, 2013 2:44 PM To: Wang, Xingchao Cc: Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; Takashi Iwai; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote: Hi Paulo/Daniel, Do you agree to export an API in gfx side for eDP case? Basically the api will let audio drver know which pipe in use. i.e. in the eDP only caes, audio driver Will know gfx is not using HDMI/DP and would like to let power-well off. As there's the conflict when user expect display audio driver always active but gfx need audio driver off. Audio driver could make decision to release power-well if it knows the eDP only case through the API. OTOH, I think audio driver could also export an API for gfx side, if gfx driver need audio driver release power-well but it's in usage, It will call this API and audio drvier will release power-well accordingly. This change make HDMI/DP hotplug handling complicated in audio driver side, if audio driver release power-well, it would enter suspend mode. Meanwhile the user may expect it's in active mode, this may cause some confuse. Afaik (and I know very little about audio) the audio side already knows which pipes have audio enabled, since we set the respective bit only when it's needed. And audio will receive the unsolicited even interrupt (or whatever it's called) when this happens. For haswell, Audio driver can get DDI port/Pin usage information according to the unsolicited event, not Pipe info. However at this stage, seems only that is enough: if no pin has valid ELD, audio driver can think about that no monitor connected with DDI ports. In this case, Audio driver could release power-well and enter suspend mode automatically
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-powersave If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. Takashi, does SUSE also use pm-utils? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-powersave If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Trying to modify the kernel to work around that would be insane. Thanks, Rafael - Intel Technology Poland sp. z o.o. z siedziba w Gdansku ul. Slowackiego 173 80-298 Gdansk Sad Rejonowy Gdansk Polnoc w Gdansku, VII Wydzial Gospodarczy Krajowego Rejestru Sadowego, numer KRS 101882 NIP 957-07-52-316 Kapital zakladowy 200.000 zl This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-power save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save Thanks --xingchao Trying to modify the kernel to work around that would be insane. Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-power save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. The former is unknown, but better to check pm-utils hooks and udev rules. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. The former is unknown, but better to check pm-utils hooks and udev rules. Okay, thank you all for pointing out to the right direction. I'm checking the pm-utils mentioned from David. :) Thanks --xingchao Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio-p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. Oh yes I found the hook: ./pm/power.d/intel-audio-powersave --xingchao The former is unknown, but better to check pm-utils hooks and udev rules. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Wang, Xingchao Sent: Wednesday, July 24, 2013 10:00 PM To: 'Takashi Iwai' Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 24, 2013 9:43 PM To: Wang, Xingchao Cc: Wysocki, Rafael J; David Henningsson; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 24 Jul 2013 13:30:16 +, Wang, Xingchao wrote: -Original Message- From: Wysocki, Rafael J Sent: Wednesday, July 24, 2013 9:15 PM To: David Henningsson Cc: Wang, Xingchao; Takashi Iwai; Paulo Zanoni; Daniel Vetter; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On 7/24/2013 1:57 PM, David Henningsson wrote: On 07/24/2013 01:33 PM, Wang, Xingchao wrote: Yes, I agree. I'm debugging this issue on Ubuntu, not sure it happens on other distribution too. If it's related to Ubuntu, maybe need check Ubuntu power policy. Does anyone know the Ubuntu power-policy on laptop? i.e. when charger connected, will Ubuntu make decision to disable power-save feature for audio subsystem? I'm not a power management expert, but I got a pointer from my team mate to pm-utils: http://cgit.freedesktop.org/pm-utils/tree/pm/power.d/intel-audio -p ower save If I understand correctly, The scripts in power.d are executed when battery / AC-power is changed. To me, this sounds like a user space issue. It requested power on and the kernel delivered. Do you know which user-space application will touch below two flags? - /sys/devices/pci\:00/\:00\:03.0/power/control - /sys/module/snd_hda_intel/parameters/power_save The latter is touched most likely by pm-utils, one of the hooks, as David pointed. Oh yes I found the hook: ./pm/power.d/intel-audio-powersave --xingchao The former is unknown, but better to check pm-utils hooks and udev rules. Sound like it's from below hook under Ubuntu: /usr/lib/pm-utils/power.d/ pci_devices Here's the output of power control from all pci devices : xingchao@xingchao-harris-beach:~$ cat /sys/devices/pci\:00/\:00\:*/power/control on on auto ... On The only auto is for audio pci device as applied my patch. And I donot know how Ubuntu change the ac/battery policy yet. Thanks --xingchao Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote:
Hi Paulo/Daniel,
Do you agree to export an API in gfx side for eDP case?
Basically the api will let audio drver know which pipe in use. i.e. in the
eDP only caes, audio driver
Will know gfx is not using HDMI/DP and would like to let power-well off.
As there's the conflict when user expect display audio driver always active
but gfx need audio driver off.
Audio driver could make decision to release power-well if it knows the eDP
only case through the API.
OTOH, I think audio driver could also export an API for gfx side, if gfx
driver need audio driver release power-well but it's in usage,
It will call this API and audio drvier will release power-well accordingly.
This change make HDMI/DP hotplug handling complicated in audio driver side,
if audio driver release power-well, it would enter suspend mode.
Meanwhile the user may expect it's in active mode, this may cause some
confuse.
Afaik (and I know very little about audio) the audio side already knows
which pipes have audio enabled, since we set the respective bit only when
it's needed. And audio will receive the unsolicited even interrupt (or
whatever it's called) when this happens.
So I think we already have the means (albeit with that quirky hw
interface, but it seems to have been good enough for a long time already)
to do that. Or do I miss something?
-Daniel
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Thursday, July 18, 2013 7:18 AM
To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni
Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch;
intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin,
Gordon
Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 10:22 PM
To: David Henningsson
Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel
Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 16:05:43 +0200,
David Henningsson wrote:
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7]
Power-well API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report
somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check
it via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note
that many DEs change this value dynamically per AC-cable
plug/unplug depending on the configuration, and often it's
set to 0 (= no power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with
charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display
audio controller. Moreover, in this board, if no external
monitors connected, It's
using internal eDP and totally no audio support. Power-well
usage in such case also blocks some eDP features as Paulo told
me.
So I think it's not a good idea to break the rule of power
policy when charger
connected but it's necessary to add support in this particular
case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Thu, 18 Jul 2013 01:00:07 +,
Wang, Xingchao wrote:
Hi Paulo/Daniel,
Do you agree to export an API in gfx side for eDP case?
Basically the api will let audio drver know which pipe in use. i.e. in the
eDP only caes, audio driver
Will know gfx is not using HDMI/DP and would like to let power-well off.
As there's the conflict when user expect display audio driver always active
but gfx need audio driver off.
Audio driver could make decision to release power-well if it knows the eDP
only case through the API.
I don't understand this requirement. We know that no HDMI/DP is
plugged in. The problem Paulo has seen is that the power-saving isn't
kicked off just because it's turned off explicitly. In other words,
this is a system setup issue, after all.
OTOH, if HDMI/DP can be never plugged in, creating a sound device
itself doesn't make sense at all. If this is the case, we may improve
the audio driver code just to skip the devices with such
configurations.
OTOH, I think audio driver could also export an API for gfx side, if gfx
driver need audio driver release power-well but it's in usage,
It will call this API and audio drvier will release power-well accordingly.
This change make HDMI/DP hotplug handling complicated in audio driver side,
if audio driver release power-well, it would enter suspend mode.
Meanwhile the user may expect it's in active mode, this may cause some
confuse.
Yes. In general, such a force-to-suspend-the-active-stream event
should happen only when the device is really unavailable, but never be
done just for saving power.
Takashi
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Thursday, July 18, 2013 7:18 AM
To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni
Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch;
intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin,
Gordon
Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 10:22 PM
To: David Henningsson
Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel
Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 16:05:43 +0200,
David Henningsson wrote:
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7]
Power-well API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report
somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check
it via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note
that many DEs change this value dynamically per AC-cable
plug/unplug depending on the configuration, and often it's
set to 0 (= no power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with
charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display
audio controller. Moreover, in this board, if no external
monitors connected, It's
using internal eDP and totally no audio support. Power-well
usage in such case also blocks some eDP features as Paulo told
me.
So I think it's not a good idea to break the rule of power
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, July 18, 2013 2:44 PM To: Wang, Xingchao Cc: Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; Takashi Iwai; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote: Hi Paulo/Daniel, Do you agree to export an API in gfx side for eDP case? Basically the api will let audio drver know which pipe in use. i.e. in the eDP only caes, audio driver Will know gfx is not using HDMI/DP and would like to let power-well off. As there's the conflict when user expect display audio driver always active but gfx need audio driver off. Audio driver could make decision to release power-well if it knows the eDP only case through the API. OTOH, I think audio driver could also export an API for gfx side, if gfx driver need audio driver release power-well but it's in usage, It will call this API and audio drvier will release power-well accordingly. This change make HDMI/DP hotplug handling complicated in audio driver side, if audio driver release power-well, it would enter suspend mode. Meanwhile the user may expect it's in active mode, this may cause some confuse. Afaik (and I know very little about audio) the audio side already knows which pipes have audio enabled, since we set the respective bit only when it's needed. And audio will receive the unsolicited even interrupt (or whatever it's called) when this happens. For haswell, Audio driver can get DDI port/Pin usage information according to the unsolicited event, not Pipe info. However at this stage, seems only that is enough: if no pin has valid ELD, audio driver can think about that no monitor connected with DDI ports. In this case, Audio driver could release power-well and enter suspend mode automatically, this avoid blocking eDP feature enabling. And once gfx dirver Detect external monitor connected, it will also wake up audio driver. Takashi, do you think this solution acceptable? Thanks --xingchao So I think we already have the means (albeit with that quirky hw interface, but it seems to have been good enough for a long time already) to do that. Or do I miss something? -Daniel Thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Thursday, July 18, 2013 7:18 AM To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 10:22 PM To: David Henningsson Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 16:05:43 +0200, David Henningsson wrote: On 07/17/2013 04:00 PM, Takashi Iwai wrote: At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote: 2013/7/17 Wang, Xingchao xingchao.w...@intel.com: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 4:18 PM To: Wang, Xingchao Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; david.hennings...@canonical.com Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 3:34 PM To: Wang, Xingchao Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; david.hennings...@canonical.com Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote: Hi Takashi/Paulo, would you change it to auto and test again. Runtime power save should be enabled with auto. Doesn't solve the problem. Should I open a bug report somewhere? Having the power well enabled prevents some power
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Thu, 18 Jul 2013 09:23:57 +, Wang, Xingchao wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, July 18, 2013 2:44 PM To: Wang, Xingchao Cc: Paulo Zanoni; daniel.vet...@ffwll.ch; alsa-de...@alsa-project.org; Daniel Vetter; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon; Takashi Iwai; David Henningsson Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell On Thu, Jul 18, 2013 at 01:00:07AM +, Wang, Xingchao wrote: Hi Paulo/Daniel, Do you agree to export an API in gfx side for eDP case? Basically the api will let audio drver know which pipe in use. i.e. in the eDP only caes, audio driver Will know gfx is not using HDMI/DP and would like to let power-well off. As there's the conflict when user expect display audio driver always active but gfx need audio driver off. Audio driver could make decision to release power-well if it knows the eDP only case through the API. OTOH, I think audio driver could also export an API for gfx side, if gfx driver need audio driver release power-well but it's in usage, It will call this API and audio drvier will release power-well accordingly. This change make HDMI/DP hotplug handling complicated in audio driver side, if audio driver release power-well, it would enter suspend mode. Meanwhile the user may expect it's in active mode, this may cause some confuse. Afaik (and I know very little about audio) the audio side already knows which pipes have audio enabled, since we set the respective bit only when it's needed. And audio will receive the unsolicited even interrupt (or whatever it's called) when this happens. For haswell, Audio driver can get DDI port/Pin usage information according to the unsolicited event, not Pipe info. However at this stage, seems only that is enough: if no pin has valid ELD, audio driver can think about that no monitor connected with DDI ports. In this case, Audio driver could release power-well and enter suspend mode automatically, this avoid blocking eDP feature enabling. And once gfx dirver Detect external monitor connected, it will also wake up audio driver. Takashi, do you think this solution acceptable? It's the current situation, isn't it? So the question is only whether this works _as expected_. Basically system/user needs to set up two parameters for the audio power-saving. If both are set well, but it still doesn't work, we need to debug. Of course, we can improve things, for example, the default runtime PM setup. (Note that this is about the default value, not the value force to set.) Takashi Thanks --xingchao So I think we already have the means (albeit with that quirky hw interface, but it seems to have been good enough for a long time already) to do that. Or do I miss something? -Daniel Thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Thursday, July 18, 2013 7:18 AM To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 10:22 PM To: David Henningsson Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 16:05:43 +0200, David Henningsson wrote: On 07/17/2013 04:00 PM, Takashi Iwai wrote: At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote: 2013/7/17 Wang, Xingchao xingchao.w...@intel.com: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 4:18 PM To: Wang, Xingchao Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; david.hennings...@canonical.com Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API implementation for Haswell At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote: -Original Message- From: Takashi Iwai [mailto:ti...@suse.de] Sent: Wednesday, July 17, 2013 3:34 PM To: Wang, Xingchao Cc: Paulo Zanoni; alsa-de...@alsa-project.org
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features from
the graphics driver.
Is the HD-audio power-saving itself working? You can check it via watching
/sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that many DEs
change this value dynamically per AC-cable plug/unplug depending on the
configuration, and often it's set to 0 (= no power save) when AC-cable is
plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger connected, and
see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio controller.
Moreover, in this board, if no external monitors connected,
It's using internal eDP and totally no audio support. Power-well usage in
such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy when
charger connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Then, no, not in general.
If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the power_save
option and it's set up dynamically by the desktop system. We
shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used
(e.g. otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features
from the graphics driver.
Is the HD-audio power-saving itself working? You can check it via
watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that many
DEs change this value dynamically per AC-cable plug/unplug depending
on the configuration, and often it's set to 0 (= no power save) when
AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors connected, It's
using internal eDP and totally no audio support. Power-well usage in such case
also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy when
charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be changed,
instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the power_save
option and it's set up dynamically by the desktop system. We shouldn't
override it in the driver.
If the power well *must* be off when only an eDP is used (e.g. otherwise the
hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
If it's the case, controlling the power well based on the runtime PM is
likely a
bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
Thanks
--xingchao
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features
from the graphics driver.
Is the HD-audio power-saving itself working? You can check it via
watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that many
DEs change this value dynamically per AC-cable plug/unplug depending
on the configuration, and often it's set to 0 (= no power save) when
AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors connected,
It's
using internal eDP and totally no audio support. Power-well usage in such
case
also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy when
charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be changed,
instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the power_save
option and it's set up dynamically by the desktop system. We shouldn't
override it in the driver.
If the power well *must* be off when only an eDP is used (e.g. otherwise the
hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the runtime PM is
likely a
bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs
power and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long as
this parameter is set. And this is the parameter user controls, and
not what the driver forcibly sets.
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check it
via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that
many DEs change this value dynamically per AC-cable plug/unplug
depending on the configuration, and often it's set to 0 (= no
power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors
connected, It's
using internal eDP and totally no audio support. Power-well usage in
such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy
when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs
power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long as this
parameter is set. And this is the parameter user controls, and not what the
driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is active and
requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
thanks
--xingchao
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check it
via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that
many DEs change this value dynamically per AC-cable plug/unplug
depending on the configuration, and often it's set to 0 (= no
power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors
connected, It's
using internal eDP and totally no audio support. Power-well usage in
such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy
when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs
power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long as this
parameter is set. And this is the parameter user controls, and not what the
driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is active
and requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
On our driver we try to disable the power well whenever possible, as
soon as possible. We don't change our behavior based on power AC or
other user-space modifiable behavior (except the
i915.disable_power_well Kernel option). If the power well is not
disabled we can't enable some features, like PSR (panel self refresh,
and eDP feature) or PC8, which is another power-saving feature. This
will also make our QA procedures a lot more complex since when we want
to test specific features (e.g., PSR, PC8) we'll have to disconnect
the AC adapter or run scripts. So the behavior/predictability of our
driver will be based on the Audio driver power management policies.
I am not so experienced with general Linux Power Management
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
At Wed, 17 Jul 2013 10:31:26 -0300,
Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check it
via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that
many DEs change this value dynamically per AC-cable plug/unplug
depending on the configuration, and often it's set to 0 (= no
power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors
connected, It's
using internal eDP and totally no audio support. Power-well usage in
such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy
when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs
power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long as this
parameter is set. And this is the parameter user controls, and not what
the
driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is active
and requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
On our driver we try to disable the power well whenever possible, as
soon as possible. We don't change our behavior based on power AC or
other user-space modifiable behavior (except the
i915.disable_power_well Kernel option). If the power well is not
disabled we can't enable some features, like PSR (panel self refresh,
and eDP feature) or PC8, which is another power-saving feature. This
will also make our QA procedures a lot more complex since when we want
to test specific features (e.g., PSR, PC8) we'll have to disconnect
the AC adapter
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300,
Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +,
Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +,
Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check it
via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that
many DEs change this value dynamically per AC-cable plug/unplug
depending on the configuration, and often it's set to 0 (= no
power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio
controller. Moreover, in this board, if no external monitors
connected, It's
using internal eDP and totally no audio support. Power-well usage in
such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy
when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should be
changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the runtime PM
is likely a bad design, as it relies on the parameter user sets.
(And remember that the power-saving of the audio can be disabled
completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active, it needs power
and should request power-well from gfx side.
In above case, audio controller should not be active but user set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long as this
parameter is set. And this is the parameter user controls, and not what the
driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is active and
requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
On our driver we try to disable the power well whenever possible, as
soon as possible. We don't change our behavior based on power AC or
other user-space modifiable behavior (except the
i915.disable_power_well Kernel option). If the power well is not
disabled we can't enable some features, like PSR (panel self refresh,
and eDP feature) or PC8, which is another power-saving feature. This
will also make our QA procedures a lot more complex since when we want
to test specific features (e.g., PSR, PC8) we'll have to disconnect
the AC adapter or run scripts. So the behavior/predictability of our
driver will be based on the Audio driver power management policies.
So all missing feature are about the power saving?
I am not so experienced with general Linux Power Management code, so
maybe the way the Audio driver is behaving is just the usual way, but
I
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 10:22 PM
To: David Henningsson
Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang xingchao;
Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 16:05:43 +0200,
David Henningsson wrote:
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300,
Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report
somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check
it via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note
that many DEs change this value dynamically per AC-cable
plug/unplug depending on the configuration, and often it's
set to 0 (= no power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger
connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display
audio controller. Moreover, in this board, if no external
monitors connected, It's
using internal eDP and totally no audio support. Power-well
usage in such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power
policy when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A
controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this should
be changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't work properly), then it's a
different story. Is it the case? And what exactly would be the
problem?
In the eDP only case, no audio is needed for the HD-A
controller, so it's
wasting power in current design.
I think Paulo or Daniel could explain more details on the impact.
Consuming more power is the expected behavior. What else?
If it's the case, controlling the power well based on the
runtime PM is likely a bad design, as it relies on the parameter user
sets.
(And remember that the power-saving of the audio can be
disabled completely via Kconfig, too.)
From audio controller's point of view, if it's asked be active,
it needs power
and should request power-well from gfx side.
In above case, audio controller should not be active but user
set it be
active.
By setting the autopm on, user expects that no runtime PM happens.
In other words, the audio controller must be kept active as long
as this parameter is set. And this is the parameter user
controls, and not what the driver forcibly sets.
Okay, become clear now. :)
So I think the conflict for Paulo becomes, in eDP caes, if audio is
active
and requested power-well, some eDP feature was under impact?
Paulo, would you clarify this in more details?
On our driver we try to disable the power well whenever possible,
as soon as possible. We don't
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Paulo/Daniel,
Do you agree to export an API in gfx side for eDP case?
Basically the api will let audio drver know which pipe in use. i.e. in the eDP
only caes, audio driver
Will know gfx is not using HDMI/DP and would like to let power-well off.
As there's the conflict when user expect display audio driver always active but
gfx need audio driver off.
Audio driver could make decision to release power-well if it knows the eDP only
case through the API.
OTOH, I think audio driver could also export an API for gfx side, if gfx driver
need audio driver release power-well but it's in usage,
It will call this API and audio drvier will release power-well accordingly.
This change make HDMI/DP hotplug handling complicated in audio driver side, if
audio driver release power-well, it would enter suspend mode.
Meanwhile the user may expect it's in active mode, this may cause some confuse.
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Thursday, July 18, 2013 7:18 AM
To: 'Takashi Iwai'; David Henningsson; Paulo Zanoni
Cc: alsa-de...@alsa-project.org; Daniel Vetter; daniel.vet...@ffwll.ch;
intel-gfx@lists.freedesktop.org; Wang xingchao; Girdwood, Liam R; Jin, Gordon
Subject: RE: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 10:22 PM
To: David Henningsson
Cc: Paulo Zanoni; Wang, Xingchao; alsa-de...@alsa-project.org; Daniel
Vetter; daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; Jin, Gordon
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well API
implementation for Haswell
At Wed, 17 Jul 2013 16:05:43 +0200,
David Henningsson wrote:
On 07/17/2013 04:00 PM, Takashi Iwai wrote:
At Wed, 17 Jul 2013 10:31:26 -0300, Paulo Zanoni wrote:
2013/7/17 Wang, Xingchao xingchao.w...@intel.com:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 4:18 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7] Power-well
API implementation for Haswell
At Wed, 17 Jul 2013 08:03:38 +, Wang, Xingchao wrote:
-Original Message-
From: Takashi Iwai [mailto:ti...@suse.de]
Sent: Wednesday, July 17, 2013 3:34 PM
To: Wang, Xingchao
Cc: Paulo Zanoni; alsa-de...@alsa-project.org; Daniel Vetter;
daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; Wang
xingchao; Girdwood, Liam R; david.hennings...@canonical.com
Subject: Re: [alsa-devel] [Intel-gfx] [PATCH 0/4 V7]
Power-well API implementation for Haswell
At Wed, 17 Jul 2013 02:52:41 +, Wang, Xingchao wrote:
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report
somewhere?
Having the power well enabled prevents some power saving
features from the graphics driver.
Is the HD-audio power-saving itself working? You can check
it via watching /sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note
that many DEs change this value dynamically per AC-cable
plug/unplug depending on the configuration, and often it's
set to 0 (= no power save) when AC-cable is plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with
charger connected,
and see the default parameter auto=on.
In such scenario, power-well is always occupied by Display
audio controller. Moreover, in this board, if no external
monitors connected, It's
using internal eDP and totally no audio support. Power-well
usage in such case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power
policy when charger
connected but it's necessary to add support in this particular
case.
Takashi, do you think it's acceptable to let Display audio
controller/codec
suspend in such case?
Do you mean the driver enables the powersave forcibly?
Yes. I mean call pm_runtime_allow() for the power-well HD-A
controller.
Then, no, not in general.
If the default parameter of autopm is the problem, this
should be changed, instead of forcing the policy in the driver.
OTOH, the audio codec's powersave policy is governed by the
power_save option and it's set up dynamically by the desktop
system.
We shouldn't override it in the driver.
If the power well *must* be off when only an eDP is used (e.g.
otherwise the hardware doesn't
Re: [Intel-gfx] [alsa-devel] [PATCH 0/4 V7] Power-well API implementation for Haswell
Hi Takashi/Paulo,
would you change it to auto and test again.
Runtime power save should be enabled with auto.
Doesn't solve the problem. Should I open a bug report somewhere?
Having the power well enabled prevents some power saving features from
the graphics driver.
Is the HD-audio power-saving itself working? You can check it via watching
/sys/class/hwC*/power_{on|off}_acct files.
power_save option has to be adjusted appropriately. Note that many DEs
change this value dynamically per AC-cable plug/unplug depending on the
configuration, and often it's set to 0 (= no power save) when AC-cable is
plugged.
[Wang, Xingchao] Paulo used a new Ultrabook board with charger connected, and
see the default parameter auto=on.
In such scenario, power-well is always occupied by Display audio controller.
Moreover, in this board, if no external monitors connected,
It's using internal eDP and totally no audio support. Power-well usage in such
case also blocks some eDP features as Paulo told me.
So I think it's not a good idea to break the rule of power policy when charger
connected but it's necessary to add support in this particular case.
Takashi, do you think it's acceptable to let Display audio controller/codec
suspend in such case?
Thanks
--xingchao
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
