[alsa-devel] HD-Audio: Is it okay to delay resuming codecs when resuming from S3?
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.
Regards Mengdong
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.
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.
Takashi
-----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
At Tue, 26 Nov 2013 12:16:47 +0000, Lin, Mengdong wrote:
-----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.
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.
Okay. And is it okay to parallel resuming multiple codecs, also using the bus work queue to parallel suspending codecs?
Yes.
Takashi
participants (2)
-
Lin, Mengdong -
Takashi Iwai