GTA04 PMU / Core arch block diagram v1

Andy Green andy at openmoko.com
Wed Apr 2 17:03:20 CEST 2008


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

Somebody in the thread at some point said:
| Andy Green wrote:
|> Consequently though if the backlight goes down, quite often I think we
|> find that any reason for the CPU to be up just evaporated as well.
|
| Yes, but keeping the CPU turned off shouldn't be a goal per se. If it
| briefly powers on to handle a volume control or mute event, that has
| no real effect on our battery life.

But it has effects on latency.  Today the resume latency on GTA02 is
very noticeable.  I think it is important that when the user clicks a
button for some function, as far as we can manage it, it does not
hesitate sometimes and not others.

|> What is "usage policy"?  The user defines "usage" when he interacts with
|> the device.
|
| Things like "what does this button do". E.g., you may use button X

"functionality" then.

| (AUX, POWER, RIGHT, ...) to hang up. But then someone may want to
| make a GUI that asks for confirmation. So if the MPU doesn't only
| report the button press to the CPU but also takes further actions,
| that GUI change would need a different MPU firmware, or the MPU
| firmware would need to have a configurable action.

We can make the MPU button reactions soft too, held in MPU RAM (if we
lost RAM on MPU, we will definitely boot Linux again anyway and
reconfigure it).  Most functions of the MPU don't have overloads, for
example the touchscreen and motion always just do what they do.  So we
really set button or gesture MPU actions in one byte or so.

| Similarly, volume control: some user interface designs give you
| acoustic or even visual feedback when the volume changes. And they
| may differ in how they handle changes at the end of the range.
| Again, if the MPU tries to handle this autonomously, each different
| UI needs to change MPU behaviour.

Not really.  As in the hangup example, the MPU does not hang up, it
stops the audio while it wakes the processor to hang up.  To the user he
got instant action every time from the hang up UI event.  So where the
MPU can react immediately to fill in the gap it is really good even if
it does not do the full action.

If the particular GUI leaves nothing to be filled in, it can configure
the MPU mapping to not take any action and do it all itself after a pause.

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

iEYEARECAAYFAkfzoDEACgkQOjLpvpq7dMqI8gCfcalFCXM8TU6cKhkuU4pQknlH
S/0An3jtKl0U0u/xpg2Krm/L9xP+qigh
=y0O/
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list