At Thu, 3 Dec 2009 17:58:08 +0530,
Chaithrika U S wrote:
>
> On Wed, Dec 02, 2009 at 14:56:31, Takashi Iwai wrote:
> > At Wed, 2 Dec 2009 12:39:00 +0530,
> > Chaithrika U S wrote:
> > >
> > > diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c
> > > index ad4d7f4..80c7fdf 100644
> > > --- a/sound/soc/davinci/davinci-pcm.c
> > > +++ b/sound/soc/davinci/davinci-pcm.c
> > > @@ -49,7 +49,7 @@ static void print_buf_info(int slot, char *name)
> > > static struct snd_pcm_hardware pcm_hardware_playback = {
> > > .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
> > > SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
> > > - SNDRV_PCM_INFO_PAUSE),
> > > + SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME),
> >
> > Note that unless your driver supports the "full" resume,
> > SNDRV_PCM_INFO_RESUME shouldn't be set. Here, the "full" resume means
> > that the hardware gets back to a completely sane state and the PCM
> > streams are resumed without extra PCM prepare call at PM resume.
> > If the PCM (or whatever) needs another re-initialization (like in many
> > cases), don't set this flag.
> >
> > Just to be sure...
> >
> >
> > Takashi
> >
>
> PCM prepare call is not needed in this case. Testing was done with audio
> loopback and after a suspend/resume cycle the audio output was proper. Hope
> my understanding is correct. Is this test sufficient to prove that driver
> supports full resume?
Yeah, if it worked with an actual app, it's fine :)
That was just a slight concern.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
