GTA04 PMU / Core arch block diagram v1

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

Absolutely, in fact wake scheduling generally is in that too.

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

I don't know we should use it, although providing it for command
injection to MPU might be good for debug (and later you give the policy
setup example).

If I think about it from the other end first, it is an SPI link to the
MPU, because some of the data is sensitive to overall latency (ie,
touchscreen coords) we need to be polling SPI packets out of the MPU
probably by interrupt (because if there is no touchscreen "touch", and
no motion, there might be no traffic).

When we get a packet from the MPU, we need to parse and push things into
the input event subsystem right there, so buttons are seen as pressed,
update /dev/ts0 or whatever it is for touchscreen and so on.

So pretty much as soon as we took the packet we routed all the
information into existing Linux subsystems and /dev nodes in their
native protocol.  It means the getdata example doesn't fit well because
you can get it from the motion sensor /dev/input/event2 or whatever already.

Looking at the other end, "powerdown audio", really only the audio
driver is okay to say that, and then it is in kernelspace and can queue
it via some API.  Setting the alarm generally would be done by RTC class
object and then again it can send the request to MPU itself.

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

Yeah this is good, I had the same idea.  And actually you will indeed
need a way to set the immediate actions from userspace be it /dev/mpu or
/sys/mpu_actions or something.

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

Yes this is a real core decision about the core.  I think it makes a
chance for breakout battery life to come at it in this direction.

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

iEYEARECAAYFAkfzpNcACgkQOjLpvpq7dMpq8gCfZky/ThlNeN8ZmfsjmOPbPfO4
htcAn0Zsua2Usi0lawqF4upJCHvXjWAT
=YGQQ
-----END PGP SIGNATURE-----