GTA04 PMU / Core arch block diagram v1

[Andy Green]

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

Somebody in the thread at some point said:
| On Tue, Apr 01, 2008 at 06:43:14PM -0300, Werner Almesberger wrote:
|> Andy Green wrote:
|>> Corner cases like hangup action, reacting to mute, going to handsfree
|>> and plugging the headphones in should be instant with no deadtime if the
|>> CPU is there or not.
|> Hmm, I'm just a bit afraid that we may end up building yet another
|> u-boot if the MPU gets to do too much. Small tight real-time things
|> (such as speaking HDQ), high-frequency events (integration of
|> accelerometer results), and low-level power management (PMU bringup),
|> yes, by all means, but things like hangup management sound rather
|> like the sort of policy best done in user space to me ...
|
| I agree with werner.  You also should keep in mind that if too much
| functionality is implemented in the MPU, then more people will feel that
| they have to re-program it, resulting in the possibility to brick it,
| re-generating the need for some kind of MPU un-bricking feature, just
| like we have for the CPU.

Well as on the picture MPU is planned to be part of the JTAG scanchain,
and FTDI is planned to be on the motherboard.  So bricking is less of a
worry.

The other point is a little bit of a strawman, nobody suggested whole
"hangup management" in the MPU.  If a button action could be associated
with canned codec register changes, that can be leveraged a few ways,
volume up / down, headphone insert handled and in this case "immediate
hangup".

On the general point though yes the more we pile on the little MPU the
more trouble we can make for ourselves, it needs care for sure.

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

iEYEARECAAYFAkf04aQACgkQOjLpvpq7dMrdeQCdHvcqzCFkvvidvgjdVOxCyyAU
HFkAnjzRHyJvEkoHsLCOvM4BBN4M++Pp
=G+Ve
-----END PGP SIGNATURE-----