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