Suspend and Resume speed
andy at openmoko.com
Wed Jun 11 20:54:06 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3855 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080611/469bd99d/attachment.bin
More information about the openmoko-kernel