wm8960 sleep time is too long when system suspend

wm8960 sleep time is too long when system suspend

[Zidan Wang]

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

Re: wm8960 sleep time is too long when system suspend

[Charles Keepax]

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

Re: wm8960 sleep time is too long when system suspend

[Zidan Wang]

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

Re: wm8960 sleep time is too long when system suspend

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 739 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: wm8960 sleep time is too long when system suspend

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 540 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]