GTA04 PMU / Core arch block diagram v1

[Mathias Bösl]

>
> There's more scope for these "hard-acting" IO events now the MPU will
> monitor the UI IO.
IMO there are not only IO event which should "never break", but things 
like the timer for the alarm clock.

> | 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
> 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,
How do you think about implement a small kind of api / abi in the MPU 
that can be accessed by the CPU in user space combined with something 
like a "event queue" that lives in MPU RAM ?

The Idea:
First create a virtual device /dev/mpu which represents the MPU in user 
space and can be accessed something like

# echo "powerdown audio" > /dev/mpu
# echo "setdata alarmtime 08:00" > /dev/mpu
# echo "getdata motionsensor" > /dev/mpu | /bin/someApplication

This way you can use the MPU as "latch" if CPU is up.

The second thing is the "event queue" which means the MPU has a queue of 
commands in RAM that has to be executed on special events. Every command 
itself is written in the ROM. So you only need one byte to choose the 
command.

examples:
Powerbutton pressed event : <powerup PLLs> , <start Clock>, <powerup 
Backlight>, <resume CPU> 

or something like that. This way the usage Policy (which I think IS very 
useful) can be done by MPU (rapid response), Policy can changed easily 
(by writing the new queue to  /dev/mpu) without flashing. Another point 
is that you get a very high amount of openness because you can change 
virtually the whole behavior of you moko.


I am reading the openmoko.kernel ml for about 2 months and i like 
(almost) everything i read here, but this problem IMO is very important 
and could choose the direction in which the whole openmoko will go.


Mazze