[alsa-devel] wm8960 sleep time is too long when system suspend
Hi Mark,
In wm8960 codec driver, suspend_bias_off has been enabled. So when system suspend, the wm8960 codec will go to bias off, it will disable VMID and VREF, then sleep 600ms. It seems that 600ms is too long for system suspend.
Because the wm8960 datasheet don't mentioned the sleep time, so i want to check with you if we can shorten the sleep time.
Best Regards, Zidan Wang
On Mon, Nov 02, 2015 at 04:44:04PM +0800, Zidan Wang wrote:
Hi Mark,
In wm8960 codec driver, suspend_bias_off has been enabled. So when system suspend, the wm8960 codec will go to bias off, it will disable VMID and VREF, then sleep 600ms. It seems that 600ms is too long for system suspend.
Because the wm8960 datasheet don't mentioned the sleep time, so i want to check with you if we can shorten the sleep time.
I can't say that I am explicit familiar with the required delay there, but the comment in the code says that we are letting VMID and VREF discharge, which I certainly could believe would take a while. My guess would be that we likely weren't super excited about putting a 600mS delay in, which probably means it was necessary for some reason.
How much where you hoping to reduce it by? I can see if I can find a hardware engineer who still remembers enough about the part to discuss it with.
Thanks, Charles
On Mon, Nov 02, 2015 at 09:18:55AM +0000, Charles Keepax wrote:
On Mon, Nov 02, 2015 at 04:44:04PM +0800, Zidan Wang wrote:
Hi Mark,
In wm8960 codec driver, suspend_bias_off has been enabled. So when system suspend, the wm8960 codec will go to bias off, it will disable VMID and VREF, then sleep 600ms. It seems that 600ms is too long for system suspend.
Because the wm8960 datasheet don't mentioned the sleep time, so i want to check with you if we can shorten the sleep time.
I can't say that I am explicit familiar with the required delay there, but the comment in the code says that we are letting VMID and VREF discharge, which I certainly could believe would take a while. My guess would be that we likely weren't super excited about putting a 600mS delay in, which probably means it was necessary for some reason.
How much where you hoping to reduce it by? I can see if I can find a hardware engineer who still remembers enough about the part to discuss it with.
Some customer can't accept such long system suspend time. It's better to spend less than 100ms for system suspend. Codec suspend is a part of system suspend, so it should be less than 100ms, and as short as possible.
Best Regards, Zidan Wang
Thanks, Charles
On Mon, Nov 02, 2015 at 06:49:23PM +0800, Zidan Wang wrote:
Some customer can't accept such long system suspend time. It's better to spend less than 100ms for system suspend. Codec suspend is a part of system suspend, so it should be less than 100ms, and as short as possible.
Users need to be realistic about the performance they can expect with older devices. Systems that need fast power on/off times should be using ground referenced CODECs, fundamentally ramping VMID quickly is incompatible with avoiding pops and clicks.
On Mon, Nov 02, 2015 at 04:44:04PM +0800, Zidan Wang wrote:
Hi Mark,
Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to.
In wm8960 codec driver, suspend_bias_off has been enabled. So when system suspend, the wm8960 codec will go to bias off, it will disable VMID and VREF, then sleep 600ms. It seems that 600ms is too long for system suspend.
Because the wm8960 datasheet don't mentioned the sleep time, so i want to check with you if we can shorten the sleep time.
These times are totally normal for a VMID referenced CODEC like the wm8960, attempting to ramp faster produces audible artifacting.
participants (3)
-
Charles Keepax -
Mark Brown -
Zidan Wang