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

[Nobin Mathew]

i was getting those overrun issue because of one controller bug, if i
write zero to TXCR/RXCR register to disable both transmit and receive
logic before low power mode then i am getting this overrun error after
resume.


Thanks a lot for your help

Thanks
Nobin Mathew



On 5/28/07, Nobin Mathew <nobin.mathew at gmail.com> wrote:
> 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
> > >
> >
> >
>