Suspend and Resume speed

Andy Green andy at
Wed Jun 11 17:31:46 CEST 2008

Hash: SHA1

Hi Mark -

I noticed today that our resume on defconfig-2.6.24 takes ~1.3s, and
that almost all of that is because of glacial i2c register restoring in
resumes of pcf50633 (450ms) and soc-audio (700ms): together it's 1150ms
of the 1300ms.

The pcf50633 resume was able to be reduced to 255ms by using a one-hit
block i2c transaction instead of individual ones and other
optimizations, but the WM8753 datasheet does not mention that it is able
to cope with autoincrementing register addresses like that.

So I made a little experimental patch that defers the guts of soc-audio
resume action into an immediately-scheduled workqueue that runs in
parallel with the rest of resume.  The advantage for us is that resume
to userspace unfrozen is then reduced to ~450ms from 1300ms or 3 times
faster total.

It "works", audio is OK after resume, but it does not have any locking
to stop races with other stuff wanting to touch codec registers while it
is completing.  Do you have any ideas how to have it block other access
to codec registers until it completes without making a locking Hell or
lots of invasiveness?  It's fine if audio related userspace is going to
block briefly until it is fully resumed, instead of whole of userspace
is frozen until soc-audio completes resuming.

I attach the patch without locking for reference (not because it is safe
to use).

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -

-------------- next part --------------
A non-text attachment was scrubbed...
Name: experimental-soc-audio-resume-in-workqueue.patch
Type: text/x-patch
Size: 4113 bytes
Desc: not available
Url : 

More information about the openmoko-kernel mailing list