From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nobin Mathew" Subject: Re: Power management state flow in ALSA Date: Wed, 30 May 2007 16:06:54 +0530 Message-ID: <8d6898730705300336l4db252e6pa4b7b257de4ed6eb@mail.gmail.com> References: <8d6898730705292322w2dbf2a2fu4761370c4cc7ea16@mail.gmail.com> <8d6898730705300306g3f32f5e8yad6770a4eee1851a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by alsa0.perex.cz (Postfix) with ESMTP id 525E22445C for ; Wed, 30 May 2007 12:36:55 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id n7so1105478wag for ; Wed, 30 May 2007 03:36:54 -0700 (PDT) In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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 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 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 > > > > > >