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