GTA04 PMU / Core arch block diagram v1

Andy Green andy at
Wed Apr 2 14:02:53 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> 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.
| Yup, absolutely. But there are also very few such items that have
| a defined response without involving the display.

There's more scope for these "hard-acting" IO events now the MPU will
monitor the UI IO.  There are "few such items" until now because it
wasn't an option due to CPU-centric architecture.

|> If it means going behind the driver model's back somehow then "not
|> fine".
| It's a general problem, not only an issue relevant to OpenMoko. So
| whatever we do has to be coordinated with the rest of the kernel

Well I can't discuss what isn't really defined.

|> I think when we map it out, we will find that a major requirement to
|> interact with the LCM graphically is the watershed
| Yes, the LCM takes a long time to power up, even more time to read,

I'm sure whatever LCM we use we can power it up quickly if we want.  The
smooth brightness ramp is just a cosmetic feature not a requirement.
You don't have to red it really if you powered it up so you can tap out
a phone number, a glance will do.  The connection between backlight and
CPU is more that we have to have the CPU (and LCD unit) up if we ever
light the LCM backlight, or there will simply be no image on it.
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.

|> 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
| Hmm, then you start moving usage policy into the MPU. I agree that

What is "usage policy"?  The user defines "usage" when he interacts with
the device.

| the system should be as much off as possible for as much of the
| time as possible. But policy decisions belong into user space. You
| don't want to have to flash new MPU firmware just when you add a
| new application that, say, needs to wake up to collect GPS data
| every once in a while.

Consider that GPS app opens a socket or dev node, writes "60s" down it
to queue a wakeup event with the MPU, and then does a blocking read.
The CPU suspends in the meantime, when we get woke with that cookie the
read unblocks and the GPS app does its thing before looping.

So "policy" and fulfilment lives on the CPU in userspace, enforcement
lives on the MPU, there is nothing there about having to flash new
firmware on the MPU to change it.

| I think the same philosophy should apply to the MPU. Things shouldn't
| be done in the MPU because we can, but only if we can't do them

Yeah right, as in the example above, we need to use it straegically, not
necessarily deeply.  We shouldn't assume if we do that, that the MPU
makes trouble -- the always-on, fast reaction aspect of the MPU is a big
advantage is we are smart about how we build it in.

- -Andy

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


More information about the openmoko-kernel mailing list