GTA series power design / relative power used by CPU and MPU

Andy Green andy at
Thu Apr 3 19:09:12 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|>  whatever the backbone for the timer scheduling is, it needs to be a bit
|>  abstracted because on these devices it may actually be queuing wake
|>  timer events at the MPU, not inside Linux.
| That's the design that is planned for GTA03 but it's not that of most
| Linux phones, and freesmartphone as I understand it is attempting to
| bring standards for the whole range of Linux smart phones, not GTA03
| only.

Being serious about keeping the CPU (and DRAM) down doesn't mean that we
violate what this power management API is trying to do.  As I said above
it just means to make an abstraction as to where the wake timer actually
is, because it doesn't have to be in the CPU.

| IMHO that design with the MPU is kind of taking Linux out of the Linux
| phone that Neo was planned as, making it a dumb phone with a (slightly
| unneeded) cpu attached to it - Qualcomm style.  I can understand the

Well this isn't the proposal.  The MPU wants the buttons, the LEDs, the
PMU, the backlight and so on, it doesn't actually talk to the GSM or the
GPS or bluetooth or WLAN or anything complicated.  Let Linux do what
Linux is good at and hand off the rest to something that does it with
100% immediate consistency and no excuses because something blocked on
garbage collection or hoovering libs out of NAND or some drivers stutter
on resume.

In the case the CPU wants to be up all the time, that's fine too.  Just
as a phone, most times that isn't wanted, great battery life is wanted
by default.

What the MPU IS doing is taking low level crap we do badly on GTA02 like
battery/charger management and implementing it in an absolutely solid
way we reuse over multiple products, even if the CPU changes.

| exactly for ultra low power operation and they are really good at it
| (OMAP may be slightly more successful than S3Cxxxx), probably not much
| worse than the MPU you chose, even adding the RAM power. That is, if

"Probably not much", huh.  When the MSP430 goes to idle itself,


... see p20... the standby modes run from 500nA to 84uA at 1MHz.  To put
it in scale a grounded 100K pullup to 3.3V pulls 33uA.  Most of the time
when the phone is idle the MPU will be idle too, but at 16MHz the MPU
eats 6mA.

The 6400 data we have at the moment is silent about power, but looking
at the 2442 (p47 of the RAM bit), even when we really *suspend* the
*RAM* in the CPU, it eats 250uA just sitting there, enough for 3 MPUs at
1MHz and it's just the RAM.  If we power the RAM out of selfrefresh to
prepare to actually use it, active standby in "power down mode" with
clock eats 6mA all by itself.  Operating current with 1 bank active: 90mA.

| the software side is driving them correctly (but this is also going to
| be a problem on the MPU).  The CPU may consume twenty times more power
| than MPU but it's still hardly noticeable compared to the modem + LCD
| backlight + everything else.

Sure, but we will dim and turn off the backlight as soon as possible.
Then unless we needed the CPU for something specific, why is it and its
RAM and its PLLs drinking our precious power?  It's no good to wave
hands and say "the CPU may consume 20 times more power, but... xyz is
worse we are all doomed" if we want to reach towards the top shelf on
battery life.  We need to keep stuff down by default and be clever about
having the minimum up the minimum amount of time to provide the service
defined, everything else above that is power eating bloat.

| what it's designed for. So I don't think the new design brings that
| much energy saving in daily use.  If it could be used to at least
| replace the PMU then it would make more sense, but at this point you
| have three processors trying to manage the power issues together.

PMU isn't a processor, it's a peripheral with registers that can be set
by a processor.  It doesn't take code.

Hey look at it this way, if the defensive action of placing power
enforcement in the MPU along with resume delay hiding tricks turns out
to not be needed because the CPU power management is even better than
the 500nA MPU and resume time is measured in ns (well, I am kidding),
then we just use the "traditional" CPU-centric model where it makes
sense.  The MPU itself doesn't disallow it, this is a virtual soft
decision.  But in the expected case where it makes solid power savings,
we are already set up to exploit that.  -- And we did the architectural
work to ensure we allow suspended-CPU phone calls and so on that I
didn't see mentioned before this effort.

Over weeks of standby very small absolute differences in power
consumption add up to extra days.

- -Andy

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


More information about the openmoko-kernel mailing list