Re: [ALSA] ALSA Power Management, Drivers behaving unexpectedly after suspend/resume cycle

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux