Post- GTA02

[Andy Green]

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

Somebody in the thread at some point said:

> If mainCPU is awaking on one byte that has completed in uart. enters 
> IRQ-handler to fetch the byte(s) from fifo, does an occasional string concat 
> and some calculations etc, and goes to sleep again waiting for next IRQ, 
> there will 0 dead time and overall power consumption might be less than that 
> of the MPU in allways-on mode. But it's hard to design, given you don't 
> create the chips from scratch.

There's sleep and sleep: in suspend where we get the best power savings
power is actually removed from the CPU core completely and the PLLs
turned off.  The DRAM is also put into a low power selfrefresh state.

In the 6400 they have multiple PLLs that are async and allows much
better scaling of the clocks in the system without grief, so I guess it
helps.

> Yep, ACK. But we see here it's not really trivial. Above consideration has to 
> be done carefully for each and every possible source of interesting data.
> Of course there has to be GSM, GPS, Hold / jackinsert, WLAN, BT, BAT-HDQ & PMU 
> and probably TouchScreen, all has to be checked for possible scenarios of use 
> a MPU couldn't handle, and for conditions worth to be monitored to trigger a 
> wake.

Right, it is not trivial to do this properly.  Charger management is
another big one.  But we have to do it somewhere, we have to select a
finite set of wake stimulus at some point with the CPU too.  Trying to
manage things in the CPU when the CPU is not always alive will always
make for discontiguities.

> Especially the low level things are more hard to keep open - let's assume some 
> weird example: I have an ambient light sensor and I havea LED in the switch. 
> When I decide to use the photodiode for learning commands from my TV-remote 
> and then send these via the LED, I can easily do so as long as these 

I don't think the sensor would have the bandwidth to respond, but ok.

> components are driven directly by main CPU GPIO. A MPU probably wouldn't be 
> designed to do this highspeed magic for any of both.

The MPU is flash and reprogrammable, so there is flexibility to do what
it can.  But I take your point, it is a boundary.  We have to be smart
about what we put on the "always-on" side of the boundary away from the
CPU, how we communicate about events to the CPU, what information we
potentially lost and so on.

> For a more feasible thing: wake up on noise (we have a mic!), e.g. for a 
> babyfone. How to do this? Yeah i know it's not easy (or better: impossible) 
> without MPU either, i only want to point out there's a lot to think about to 
> keep the whole thing as "open" as possible, as adding complexity always 
> reduces flexibility.

Well plug the thing in the wall and don't let it sleep, you can do your
audio detection in Linux fine.  (Actually if it was a real target, the
MPU has an ADC).

> My approach with fully interupt driven main CPU is a dream that never may come 
> true due to chip limitations. However it's the way to go for "normal" power 
> management (starting with scheduler), what doesn't mean we don't need a MPU 
> to get the best from both.

There is a bit of a step in power consumption from having the CPU and
DRAM up at all and clocking vs having the core unpowered and the PLLs
off, DRAM in suspend mode.

I think we will optimize battery life by spending as much time as
possible with the main CPU completely off, and in fact the MPU using the
scheme you outline, as interrupt-driven as possible and idle the rest of
the time.  For example if we turned off the backlight, unless something
is running that countermands it (eg WLAN socket open with LISTEN, alsa
PCM is open and writing, etc), we should go into suspend right there.

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

iD8DBQFH4TVjOjLpvpq7dMoRAkQqAKCENWWEsZrapDgutJVnaDZqk8BA+ACePzrr
RKtoQV6wd/HPfZHS6QT+ssk=
=jVKo
-----END PGP SIGNATURE-----