GTA04 PMU / Core arch block diagram v1
werner at openmoko.org
Wed Apr 2 00:36:45 CEST 2008
Andy Green wrote:
> If Linux does come up in 10ms, no problemo, but I will be surprised to
> see it.
Based on the various chip timings (i.e., I haven't measured how long
things actually have to take to work), I think something like 10ms
should be feasible. For most interactions, even 100ms would probably
be sufficient for the user not to notice any lag, even for things
like volume control.
> If we don't go through the driver resumes we really will have "made
> another U-Boot" though.
*grin* Well, if we can just turn off all the things we don't care
about, and they stay turned off until we explicitly ask for them,
then we can have something pretty lean and still perfectly general.
So the call manager would turn off LCM, storage, etc., probably
through a power manager, and then ask suspend to "take care of the
rest". Resume would then have to turn on only the basics the call
manager needs to respond to state changes and to bring up more
subsystems if needed.
(Not sure if it would actually make sense for the call manager in
this scenario to have "ownership" of the device. E.g., if we're
doing a download from WLAN to SD in the background, perhaps the
power manager should take this into account and defer any suspend
until that one is done, no matter what the call manager thinks the
device should be doing. But that's the sort of policy questions
I'll happily leave to user space to decide :-)
More information about the openmoko-kernel