GTA04 PMU / Core arch block diagram v1

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| 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.

What it needs is consistency and responsiveness.  If the volume control
is physical up-down buttons that goes double -- UI event and reaction
has to feel like a direct hardware relationship that can never break.
And -->

|> 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.

If you mean that those driver resumes will happen quickly then, fine.
If it means going behind the driver model's back somehow then "not
fine".  We should either resume the CPU normally, or not at all and do
it in the MPU.

I think when we map it out, we will find that a major requirement to
interact with the LCM graphically is the watershed forcing stuff for
sure into the Linux side and accepting delay.  If we succeeded to move
into the MPU the things the user wants to treat as totally predictable
hardware operations based off UI events like button press -- that don't
use the LCM -- then for the rest actually 200 - 500ms resume while we
ramp up the backlight is probably OK for the more complex interactions
(especially if what comes up by default is contextually correct already,
eg, dialer pad / contacts).

| So the call manager would turn off LCM, storage, etc., probably

Okay brace for major heresy.

I don't think the "call manager" should have the authority to turn off
LCMs and so on.  Instead, we should have the MPU should establish a
regime that BY DEFAULT EVERYTHING IS OFF except itself -- the MPU is an
actively miserly guardian of the battery that defaults to saying "no".
Device operation of any kind (including CPU) is by default a temporary
deviation from "everything off" triggered by some UI / module event.

That would also mean Linux can be asked to suspend by the MPU.  The CPU
is then basically be a peripheral that has a SUSPEND pin, same way that
the MPU by default would bring down the backlight after some time with
no UI IO.  The CPU can override or quench the request based on, eg, open
Wifi sockets in LISTEN, but normally, it accepts to suspend.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfzVWoACgkQOjLpvpq7dMpqcwCaAqSTMCtiQI3zG0lrUy4kzz+1
QSYAn06FZby/vthceiGeH0fgisYsVUC6
=+70T
-----END PGP SIGNATURE-----