[alsa-devel] HD-Audio: Is it okay to delay resuming codecs when resuming from S3?

Lin, Mengdong mengdong.lin at intel.com
Tue Nov 26 13:16:47 CET 2013


> -----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.

> 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.

Okay. 
And is it okay to parallel resuming multiple codecs, also using the bus work queue to parallel suspending codecs?

Regards
Mengdong


More information about the Alsa-devel mailing list