Suspend and Resume speed

[Joerg Reisenweber]

Am Mi  11. Juni 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> 
> | All you should need to do to make this work is use the snd_power*() API
> | which ought to be a matter of a few lines of code above what you've got
> | already.  If the core calls snd_power_change_state() to move into
> | SNDRV_CTL_POWER_D3hot as it starts to suspend and then goes back into
> | SNDRV_CTL_POWER_D0 once resume is complete then the ALSA core will
> | ensure that user space is blocked until the resume is complete.
> 
> Excellent!
> 
> | Could you give that a spin?  If it works and survives further testing
> | it'd be good to push your revised patch out to ALSA for merge in 2.6.27
> | since it should be a noticable win for most users.
> |
> | It also occurs to me that you will be able to save a little time overall
> | by making the driver only write back registers that aren't in the
> | default state on resume rather than blindly writing them all back as the
> | code currently does.  This is probably worth doing regardless of
> | anything else, though the saving will depend on the exact configuration
> | at suspend time.  Unfortunately this won't be too big a proportion of
> | the time consumed - a lot of it will come from the power up sequencing
> | writing registers multiple times to minimising pops.
> 
> I took your advice on the nits and attach a new version of the patch.
> Thanks a lot for your hints.
> 
> I had one more realization a bit late in the day, on GTA02 Codec digital
> side is "always on", only the analogue power is switched off in suspend.
> ~ In this scenario, the regs will probably not need any reload on resume
> at all.  But I couldn't even see where all this fits into the
> mach-gta02.c world, I guess it doesn't matter now if there will be a
> general deferred resume reload of them all anyway.

Andy,
is there a way in this concept to cope with wake_on_HOLD, where we need 
mic_bias and the codec digital functions anyway (if we really want to support 
it)?
Just curious

/jOERG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080611/2c7d9bdb/attachment.pgp