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