[alsa-devel] Power management state flow in ALSA
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
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
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
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
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
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
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
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
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
Nobin,
Can you try the following patch :-
http://opensource.wolfsonmicro.com/cgi-bin/gitweb/gitweb.cgi?p=linux-2.6-aso...
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
participants (3)
-
Liam Girdwood -
Nobin Mathew -
Takashi Iwai