[alsa-devel] hda-intel and runtime power-management

[Tatulea, Dragos]

On Thu, Aug 11, 2011 at 1:01 PM, Takashi Iwai <tiwai at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snd_hda_pm_on_pcm_suspend.diff
Type: text/x-patch
Size: 4637 bytes
Desc: not available
Url : http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20110815/6f59ba8b/attachment.diff