-----Original Message----- From: Takashi Iwai [mailto:tiwai@suse.de] Sent: Tuesday, November 26, 2013 3:25 PM To: Lin, Mengdong Cc: alsa-devel@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