Re: [alsa-devel] hda-intel and runtime power-management
On Mon, Aug 8, 2011 at 9:11 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 7 Aug 2011 20:55:52 +0300, Tatulea, Dragos wrote:
I'm in the process of enabling pm runtime pm for the hda_intel
driver,
not being sure if this is a sane task :). Noticed that CONFIG_SND_HDA_POWER_SAVE disables codecs and chip when they are
not
in use, but the power gain is not noticeable on my hw. On the other hand, a full suspend (azx_suspend) does save a few hundred mW's. I am aware that this is hw specific, but I would like to take advantage of the full suspend. Suspend/resume latency is below
jiffy
resolution.
Hm, it's strange. Basically the current power-save does almost equivalent with the normal suspend/resume, i.e. the codec is suspended and azx_stop_chip() is called. Make sure that the power-saving is really kicked in during your test.
Indeed, I checked and a codec is stuck in a power transition for some
reason.
You should check who accessing the device files via fuser, etc.
Yes, there's a non-muted pcm around there that prevents the codec from sleeping. I have a patch that checks for all substream states and puts the chip to sleep when they are all paused/suspended. Is this a bad idea? It could be that resuming the chip takes too long, depending on hw...
Besides that, it would be nicer to have the currently standard runtime pm on codec bus instead of doing the same thing with CONFIG_SND_HDA_POWER_SAVE, right?
Ideally, yes, but practically it's difficult, so far, because the driver can manage multiple codecs and we need the individual codec power-up/down. With the current runtime pm scheme, it's difficult to implement like this, as it's no simple suspend/resume of the driver itself.
The codec bus can contain the generic runtime pm part which will call runtime_suspend/_resume for individual codecs, depending on usage. Each codec can register it's own dev_pm_ops.
Yes, but this would need relatively big changes in the structure of the hd-audio driver, e.g. assigning struct device per codec instance, etc.
Still looking into it, maybe there's a less invasive way of doing this.
Thanks, Dragos
At Wed, 10 Aug 2011 22:34:31 +0300, Tatulea, Dragos wrote:
On Mon, Aug 8, 2011 at 9:11 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 7 Aug 2011 20:55:52 +0300, Tatulea, Dragos wrote:
> I'm in the process of enabling pm runtime pm for the hda_intel
driver,
> not being sure if this is a sane task :). Noticed that > CONFIG_SND_HDA_POWER_SAVE disables codecs and chip when they are
not
> in use, but the power gain is not noticeable on my hw. On the other > hand, a full suspend (azx_suspend) does save a few hundred mW's. > I am aware that this is hw specific, but I would like to take > advantage of the full suspend. Suspend/resume latency is below
jiffy
> resolution.
Hm, it's strange. Basically the current power-save does almost equivalent with the normal suspend/resume, i.e. the codec is suspended and azx_stop_chip() is called. Make sure that the power-saving is really kicked in during your test.
Indeed, I checked and a codec is stuck in a power transition for some
reason.
You should check who accessing the device files via fuser, etc.
Yes, there's a non-muted pcm around there that prevents the codec from sleeping. I have a patch that checks for all substream states and puts the chip to sleep when they are all paused/suspended. Is this a bad idea? It could be that resuming the chip takes too long, depending on hw...
The PCM state check would be good.
thanks,
Takashi
On Thu, Aug 11, 2011 at 1:01 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 10 Aug 2011 22:34:31 +0300, Tatulea, Dragos wrote:
On Mon, Aug 8, 2011 at 9:11 AM, Takashi Iwai tiwai@suse.de wrote:
At Sun, 7 Aug 2011 20:55:52 +0300, Tatulea, Dragos wrote:
>> I'm in the process of enabling pm runtime pm for the hda_intel
driver,
>> not being sure if this is a sane task :). Noticed that >> CONFIG_SND_HDA_POWER_SAVE disables codecs and chip when they
are
not
>> in use, but the power gain is not noticeable on my hw. On the
other
>> hand, a full suspend (azx_suspend) does save a few hundred
mW's.
>> I am aware that this is hw specific, but I would like to take >> advantage of the full suspend. Suspend/resume latency is below
jiffy
>> resolution. > > Hm, it's strange. Basically the current power-save does almost > equivalent with the normal suspend/resume, i.e. the codec is > suspended and azx_stop_chip() is called. Make sure that the > power-saving is really kicked in during your test. > Indeed, I checked and a codec is stuck in a power transition for
some
reason.
You should check who accessing the device files via fuser, etc.
Yes, there's a non-muted pcm around there that prevents the codec from sleeping. I have a patch that checks for all substream states and puts
the
chip to sleep when they are all paused/suspended. Is this a bad idea? It could be that resuming the chip takes too long, depending on hw...
The PCM state check would be good.
I've been trying to do this for some time and it doesn't look nice or
right. See attached diff (grep from my git diff). Some feedback would be appreciated.
My approach was to keep azx stream states and count the number of running streams. On trigger, if all streams are not running then the codec will be suspended via snd_hda_power_down and eventually azx_power_notify will be called which is supposed to stop the chip. When a stream is [re]started and the running stream count goes above 0, it will wake up the codec which will wake up the chip as well. After some time debugging this code I am feeling that I've taken the wrong route... I'm also not confident that it could work on other codec configs.
Another approach would be to set the stream to mute when paused and let the codec do the amp power check which will power it down if needed. What do you think?
Thanks, Dragos
Another approach would be to set the stream to mute when paused and let the codec do the amp power check which will power it down if needed. What do you think?
PulseAudio and other equivalent layers don't pause the output. They close the ALSA sink after a timeout and reopen it when the sink/Hal state change. You may want to avoid working your tail off with a seemingly smart way of using the paused state, if in the end it's not that useful... My 2 cents, -Pierre
participants (3)
-
Pierre-Louis Bossart -
Takashi Iwai -
Tatulea, Dragos