GTA04 PMU / Core arch block diagram v1

Andy Green andy at
Wed Apr 2 00:19:19 CEST 2008

Hash: SHA1

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

Yeah but building another U-Boot is a state of mind unrelated to how
much we put on the MPU.  We need to take care about it even if we happen
not to control codec routing in there.

| (such as speaking HDQ), high-frequency events (integration of
| accelerometer results), and low-level power management (PMU bringup),

Well that's something to agree on anyway: that's the bulk of the
connectivity if we add touchscreen to "high frequency events".

| yes, by all means, but things like hangup management sound rather
| like the sort of policy best done in user space to me ...

The actual call management will have to be done in CPU userspace anyway.
~ I think if there's some question about how much hesitation the CPU
introduces we can consider to resolve it with the MPU.  So no the MPU
doesn't track call state and talk to the GSM chipset :-) but it could
terminate and perform the other audio routing tricks instantly when
prompted by IO stimulus like headset jack insert.

If Linux does come up in 10ms, no problemo, but I will be surprised to
see it.

| Well, all we really have to do before the CPU can make decisions is
| go through reset, crank up the PLLs, and bring the DRAM out of
| sleep. That should be measured in milliseconds and fast enough for
| most user interactions.

If we don't go through the driver resumes we really will have "made
another U-Boot" though.

- -Andy
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list