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:
|> Here is a first go at a diagram of the proposed core arch for the
|> s3c64x0 stuff specifically around the MPU changes.
|
| Looks good. One issue, though: why does the MPU (and not the CPU) have
| to control the audio subsystem ?

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.

I had a thought if you need the LCM to do it, you can be led to expect a
little delay while Linux comes up, and do that by getting the backlight
to illuminate nonlinearly.  Anything else you are doing driven by
buttons or gestures and so on, we should try to allow MPU to service it
without CPU so the user experiences totally consistent fast response in
these cases.  Eg, he clicks a button for hangup, or does a diagonal
touchscreen gesture on the dark LCM to hangup, that call "hangs up", the
audio is gone anyway, in milliseconds.  Always consistent -- much more
so than what users might expect through a graphical OS off NAND.  This
will really engender confidence and trust in the device I think.

| If we access the audio side through the MPU, this means that the drivers
| for these chips either have to be specific to our platform or that we
| need a "virtual I2C" driver for the MPU.

It has advantages and disadvantages.  Abstracting some things could be
an advantage on different variants.

| (NB: I think our current resume time is way too long, due to the "all
| or nothing" design of power management. So, once this is fixed, things
| like, say, volume control should be doable from the CPU, even if it
| means that it has to be woken up for a moment.)

It'll be welcome to get faster but it is still deadtime.  If we do it
right what the MPU services can be really uber solid with zero deadtime,
giving cover to hide that Linux might be coming up for example.

| Ah, and I'd add a tentative second (micro)SD slot.

Well, I don't mind it at all, but the image is just for the core part, I
didn't mean to capture all the possibilities (there are other
peripherals off 6410 like camera and so on).

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

iEYEARECAAYFAkfydcQACgkQOjLpvpq7dMqVsACfU2dMP93ZxlEaLrbKqwytlxE+
ymMAnjGiQ3gKaQNwcPmi2XLlSLYJppI3
=Dfkj
-----END PGP SIGNATURE-----