[alsa-devel] [ALSA] ALSA Power Management, Drivers behaving unexpectedly after suspend/resume cycle

[Nobin Mathew]

I think i found the issue. Issue is in controller. Soon i will get
back with more details



On 5/28/07, Nobin Mathew <nobin.mathew at gmail.com> wrote:
> I did some more investigation into this issue.
>
> There are two cases, in the first case it is working after resume()
> and in the second case it is not working after resume
>
> 1st Case:
>
> 1) boot the system
> 2)Load sound modules
> 2)mixer setting (alsactl restore 0)
> 3)Do power managemnt (sleep) suspend()
> 4)Come out of suspend, resume()
> 5)
> sound is coming out in this case
>
> 2nd Case:
> 1)boot the system
> 2)load sound modules
> 3)mixer settings (alsactl restore 0)
> 4)Do playback aplay -M /usr/share/sounds/alsa/Side_Right.wav
> 5) Let aplay to completion and kill all alsa apps if any running.
> 6)Do power managemnt (sleep) suspend()
> 7)Come out of suspend, resume()
> 8)Do playback aplay -M /usr/share/sounds/alsa/Side_Right.wav
>
> in this case no sound is coming out and i am getting underrun error.
>
>
> I am attaching some logs, these are the ac97 codec register values at
> various stages.
>
> Mainly look at the register 3c.
>
>
>
>
>
>
>
>
>
>
>
>
> On 5/25/07, Takashi Iwai <tiwai at suse.de> wrote:
> > At Fri, 25 May 2007 13:39:40 +0100,
> > Liam Girdwood wrote:
> > >
> > > On Fri, 2007-05-25 at 17:34 +0530, Nobin Mathew wrote:
> > > > Every ALSA driver is calling these for suspend
> > > >
> > > > snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
> > > > snd_pcm_suspend_all(pcm[i]);
> > > >
> > > > And for resume
> > > > snd_power_change_state(card, SNDRV_CTL_POWER_D0)
> > > >
> > > >
> > > > In ALSA ASoC no driver is calling any of this, even not in soc-core.c
> > > >
> > > > My driver is an ASoC driver and I am also not calling these functions
> > > >
> > > > Will this cause any Issue?
> > > >
> > >
> > > These should probably be called to inform the upper layers of the PM
> > > state. Can you log a bug for this in ALSA bugzilla.
> > >
> > > Fwiw, this _shouldn't_ effect your resume. You should still see calls to
> > > trigger for your DMA / AC97 to re-start transmission of PCM data.
> >
> > I think this does matter.  Without calling snd_pcm_suspend*(), the
> > stream is assumed to be still active, thus eventually neither prepare
> > nor trigger is called at resume.  If the hardware is perfectly
> > resumed as it was before suspend, it may still work somehow.
> >
> > However, usually it's impossible to resume the hardware perfectly.
> > Thus, we need one stop the stream via snd_pcm_suspend*(), and let apps
> > (or OSS layer) parepare (if needed) and restart the stream again.
> >
> >
> > Takashi
> >
>
>