Power management state flow in ALSA

Power management state flow in ALSA

[Nobin Mathew]

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.???

I am using linux kernel 2.6.17
ALSA driver version 1.0.11rc4
ASoC patch version 0.12.4

Re: Power management state flow in ALSA

[Takashi Iwai]

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

Re: Power management state flow in ALSA

[Nobin Mathew]

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.

Am i going wrong ?



On 5/30/07, Takashi Iwai <tiwai@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
>

Re: Power management state flow in ALSA

[Takashi Iwai]

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@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
> >
> 

Re: Power management state flow in ALSA

[Nobin Mathew]

Sorry for my blunders.

driver resume () is not calling snd_pcm_resume().

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@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@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
> > >
> >
>

Re: 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@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@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
> > > >
> > >
> >
> 

Re: Power management state flow in ALSA

[Nobin Mathew]

It is there in kernel see the file sound/core/pcm_native.c. but it is
static, not exported.


So no driver can call directly, may be only Ioctl.
I got it.


#ifdef CONFIG_PM
/* resume */

static int snd_pcm_pre_resume(struct snd_pcm_substream *substream, int state)
{
	struct snd_pcm_runtime *runtime = substream->runtime;
	if (!(runtime->info & SNDRV_PCM_INFO_RESUME))
		return -ENOSYS;
	runtime->trigger_master = substream;
	return 0;
}

static int snd_pcm_do_resume(struct snd_pcm_substream *substream, int state)
{
	struct snd_pcm_runtime *runtime = substream->runtime;
	if (runtime->trigger_master != substream)
		return 0;
	/* DMA not running previously? */
	if (runtime->status->suspended_state != SNDRV_PCM_STATE_RUNNING &&
	    (runtime->status->suspended_state != SNDRV_PCM_STATE_DRAINING ||
	     substream->stream != SNDRV_PCM_STREAM_PLAYBACK))
		return 0;
	return substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_RESUME);
}

static void snd_pcm_undo_resume(struct snd_pcm_substream *substream, int state)
{
	if (substream->runtime->trigger_master == substream &&
	    snd_pcm_running(substream))
		substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_SUSPEND);
}

static void snd_pcm_post_resume(struct snd_pcm_substream *substream, int state)
{
	struct snd_pcm_runtime *runtime = substream->runtime;
	snd_pcm_trigger_tstamp(substream);
	if (substream->timer)
		snd_timer_notify(substream->timer, SNDRV_TIMER_EVENT_MRESUME,
				 &runtime->trigger_tstamp);
	runtime->status->state = runtime->status->suspended_state;
	if (runtime->sleep_min)
		snd_pcm_tick_prepare(substream);
}

static struct action_ops snd_pcm_action_resume = {
	.pre_action = snd_pcm_pre_resume,
	.do_action = snd_pcm_do_resume,
	.undo_action = snd_pcm_undo_resume,
	.post_action = snd_pcm_post_resume
};

static int snd_pcm_resume(struct snd_pcm_substream *substream)
{
	struct snd_card *card = substream->pcm->card;
	int res;

	snd_power_lock(card);
	if ((res = snd_power_wait(card, SNDRV_CTL_POWER_D0)) >= 0)
		res = snd_pcm_action_lock_irq(&snd_pcm_action_resume, substream, 0);
	snd_power_unlock(card);
	return res;
}

#else

static int snd_pcm_resume(struct snd_pcm_substream *substream)
{
	return -ENOSYS;
}

#endif /* CONFIG_PM */


On 5/30/07, Takashi Iwai <tiwai@suse.de> wrote:
> 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@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@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
> > > > >
> > > >
> > >
> >
>

Re: Power management state flow in ALSA

[Takashi Iwai]

At Wed, 30 May 2007 16:06:54 +0530,
Nobin Mathew wrote:
> 
> 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 ?

I suppose so.
In soc_suspend() and soc_resume(), you can get the card instance from
codec->card, at least.

But currently SoC doesn't keep the PCM instances, so it cannot be
implemented as it is...  Liam, any plan or known issue regarding this?


Takashi

Re: Power management state flow in ALSA

[Liam Girdwood]

On Wed, 2007-05-30 at 12:58 +0200, Takashi Iwai wrote:
> At Wed, 30 May 2007 16:06:54 +0530,
> Nobin Mathew wrote:
> > 
> > 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 ?
> 
> I suppose so.
> In soc_suspend() and soc_resume(), you can get the card instance from
> codec->card, at least.
> 
> But currently SoC doesn't keep the PCM instances, so it cannot be
> implemented as it is...  Liam, any plan or known issue regarding this?
> 

I've just logged a bug :-

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3131

Should get some time to look at this later in the week.

Liam

Re: Power management state flow in ALSA

[Liam Girdwood]

Nobin,

Can you try the following patch :-

http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-asoc;a=commit;h=6c868238a5e083dca4d74439a7fd467b5c7726b0

This will notify pcm's of their suspend state.

Liam

On Wed, 2007-05-30 at 12:58 +0200, Takashi Iwai wrote:
> At Wed, 30 May 2007 16:06:54 +0530,
> Nobin Mathew wrote:
> > 
> > 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 ?
> 
> I suppose so.
> In soc_suspend() and soc_resume(), you can get the card instance from
> codec->card, at least.
> 
> But currently SoC doesn't keep the PCM instances, so it cannot be
> implemented as it is...  Liam, any plan or known issue regarding this?
> 
> 
> Takashi

Re: Power management state flow in ALSA

[Nobin Mathew]

Liam,

In soc_resume()
 we should do this
          snd_power_change_state(codec->card, SNDRV_CTL_POWER_D0);
instead of
        snd_power_change_state(codec->card, SNDRV_CTL_POWER_D3hot);

Because snd_pcm_resume in pcm_native.c expects the card to be in
SNDRV_CTL_POWER_D0 state. Other ioctl will wait forever.

static int snd_pcm_resume(struct snd_pcm_substream *substream)
{
	struct snd_card *card = substream->pcm->card;
	int res;

	snd_power_lock(card);
	if ((res = snd_power_wait(card, SNDRV_CTL_POWER_D0)) >= 0)
		res = snd_pcm_action_lock_irq(&snd_pcm_action_resume, substream, 0);
	snd_power_unlock(card);
	return res;
}


One more thing why we are using
	snd_power_change_state(codec->card, SNDRV_CTL_POWER_D3cold);
every other driver is doing
snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);

SNDRV_CTL_POWER_D3cold is true for deep sleep where power to the
controller is switched off .

In sleep, only clock to the controller is switched off.

Nobin Mathew









On 6/4/07, Nobin Mathew <nobin.mathew@gmail.com> wrote:
> Liam
>
> I will get back, i need to set up the board
>
> On 6/1/07, Liam Girdwood <lg@opensource.wolfsonmicro.com> wrote:
> > Nobin,
> >
> > Can you try the following patch :-
> >
> > http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-asoc;a=commit;h=6c868238a5e083dca4d74439a7fd467b5c7726b0
> >
> > This will notify pcm's of their suspend state.
> >
> > Liam
> >
> > On Wed, 2007-05-30 at 12:58 +0200, Takashi Iwai wrote:
> > > At Wed, 30 May 2007 16:06:54 +0530,
> > > Nobin Mathew wrote:
> > > >
> > > > 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 ?
> > >
> > > I suppose so.
> > > In soc_suspend() and soc_resume(), you can get the card instance from
> > > codec->card, at least.
> > >
> > > But currently SoC doesn't keep the PCM instances, so it cannot be
> > > implemented as it is...  Liam, any plan or known issue regarding this?
> > >
> > >
> > > Takashi
> >
> >
>