[alsa-devel] Power management state flow in ALSA

[Takashi Iwai]

At Wed, 30 May 2007 16:06:54 +0530,
Nobin Mathew wrote:
> 
> Sorry for my blunders.
> 
> driver resume () is not calling snd_pcm_resume().

As I wrote: *alsa-lib* snd_pcm_resume() function.
It's no function in the kernel.


Takashi

> 
> Suspend only calls snd_pcm_suspend ().
> 
> I am writing an ASoC driver, where i can place these calls
> 
> snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
> snd_pcm_suspend_all(chip->pcm[i]);
> 
> and snd_power_change_state(card, SNDRV_CTL_POWER_D0);
> 
> 
> In soc-core.c ?
> 
> 
> 
> On 5/30/07, Takashi Iwai <tiwai at suse.de> wrote:
> > At Wed, 30 May 2007 15:36:33 +0530,
> > Nobin Mathew wrote:
> > >
> > > In suspend () the application is dead (freezed state) before ALSA
> > > driver suspend() is called, so in this there is no way application
> > > will get to know the SUSPENDED state of driver.
> > >
> > >
> > > In resume () ALSA driver resume () (changes the state of driver) is
> > > called first and then applications are activated.
> > >
> > > So how the application will get to know the SUSPENDED state of driver
> > > through syscall.No syscall () from ALSA apps(freezed) is happening
> > > during the SUSPENDED duration of ALSA driver.
> >
> > Your app shall issue syscalls sooner or later, otherwise you'll have
> > no I/O :)
> >
> > The concept of the (PCM) resume in ALSA is a passive way.  The driver
> > does _NOT_ resume streams by itself.  It waits until the app requests
> > to resume.  This is designed so because usually the hardware cannot be
> > recovered in 100% identical state as before, and often the app needs
> > to reset something for the proper restart.
> >
> > So, when resume callback is executed and the whole kernel PM thing is
> > finished, the user-process restarts again.  Then it issues syscalls,
> > and gets to know to know that the stream is in the suspended state.
> > Now it calls alsa-lib snd_pcm_resume() function which issues RESUME
> > ioctl to restart.
> >
> >
> > Takashi
> >
> > >
> > >
> > >
> > > On 5/30/07, Takashi Iwai <tiwai at suse.de> wrote:
> > > > At Wed, 30 May 2007 11:52:31 +0530,
> > > > Nobin Mathew wrote:
> > > > >
> > > > > I am having a doubt regarding ALSA power management.
> > > > >
> > > > > My understanding of APM suspend() is like this.
> > > > >
> > > > > Freeze the ALSA apps
> > > > >
> > > > > Call ALSA driver suspend ()
> > > > >
> > > > > in the ALSA suspend() function it saves the current state of substream
> > > > > and changes the state of substream to SUSPENDED.
> > > > >
> > > > > My understanding of APM resume() is like this
> > > > >
> > > > > Call ALSA driver resume ()
> > > > >
> > > > > Activate the ALSA apps
> > > > >
> > > > > In ALSA resume function it restores the saved state of substream.
> > > > >
> > > > >
> > > > > So my question is when ALSA app will get to know the SUSPENDED state
> > > > > of substream.???
> > > >
> > > > When issuing any syscalls.  Then you'll get ESTRPIPE error, which
> > > > indicitaes the stream is in the SUSPEND state.
> > > >
> > > >
> > > > Takashi
> > > >
> > >
> >
>