GTA04 PMU / Core arch block diagram v1

[Werner Almesberger]

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.

> 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
gang. If this means changes to the driver model, and we (that is the
people involved, not necessarily just OpenMoko) can find a decent
migration strategy, so be it.

But no local hacks or such. That's the quick road to hell :-)

> 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,
and burns power like there's no tomorrow. So there we definitely
drop out of the "nanowatts are beautiful" framework.

> 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
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.

For kernel functionality, a good design philosophy is to ask whether
some new functionality really needs to be implemented in the kernel.
If it can be done in user space without too much pain, it has no
place in the kernel. Similiarly, there may only be a small part that
needs to be in the kernel, while the rest can be in user space.

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
anywhere else. The MPU will be harder to update than the kernel, most
likely harder to develop for (unique environment, according to
Milosch only incomplete development tools under Linux), and it has
tight space and cycle budget constraints.

Let's put it this way: the fewer things it does, the better it will
excel at these.

- Werner