Suspend and Resume speed
joerg at openmoko.org
Wed Jun 11 21:47:55 CEST 2008
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.
> | 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080611/2c7d9bdb/attachment.pgp
More information about the openmoko-kernel