[alsa-devel] HD-Audio: Is it okay to delay resuming codecs when resuming from S3?
tiwai at suse.de
Tue Nov 26 13:27:18 CET 2013
At Tue, 26 Nov 2013 12:16:47 +0000,
Lin, Mengdong wrote:
> > -----Original Message-----
> > From: Takashi Iwai [mailto:tiwai at suse.de]
> > Sent: Tuesday, November 26, 2013 3:25 PM
> > To: Lin, Mengdong
> > Cc: alsa-devel at alsa-project.org
> > Subject: Re: HD-Audio: Is it okay to delay resuming codecs when resuming
> > from S3?
> > At Tue, 26 Nov 2013 07:16:59 +0000,
> > Lin, Mengdong wrote:
> > >
> > > Hi Takashi,
> > >
> > > Is it okay to delay resuming codecs when resuming from S3? i.e. skip
> > snd_hda_resume() in azx_resume()?
> > >
> > > This would reduce driver resume time from S3. And the codecs will be
> > resumed when being used for the 1st time after S3.
> > >
> > > Resuming a codec may cost more than 100ms. So even if we parallel
> > resuming codecs in snd_hda_resume(), driver resume time on some
> > platforms is still a bit long.
> > This causes problems on some hardware, e.g. inconsistent mute LEDs.
> > So you cannot do it unconditionally. We did it in the past, but had to
> > switch the forced resume later.
> Thanks for the info!
> Are these problems caused by inconsistency between system assumption after S3 and audio codec HW status in D3?
> Why the mute LED can be inconsistent?
> Is the LED controlled by audio codec HW? If yes, the LED status when codec in D3 can be inconsistent from mute status before S3.
> But if the LED is controlled by software, there seems no inconsistency.
As an example, the LED is controlled via GPIO of the codec, and GPIO
pins are cleared when the controller (not the codec) goes into D3,
more specifically to RESET. In another case, the LED is controlled
via a pin VREF, and assumes that the codec won't go to D3 while the
whole operation. Thus it has to go back to D0 soon after the resume.
> > Maybe we can add a flag indicating that the codec resume may be delayed.
> > Then the bus resume checks the flags and skips the codec resume if it's
> > set.
> And is it okay to parallel resuming multiple codecs, also using the bus work queue to parallel suspending codecs?
More information about the Alsa-devel