-----BEGIN PGP SIGNED MESSAGE----- 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, http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?familyId=912§ionId=95&tabId=1528&family=mcu Eg http://focus.ti.com/docs/prod/folders/print/msp430f2370.html ... 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkf1DzgACgkQOjLpvpq7dMq76QCfYgU+R7xguib1uzk0+k3LHjmY 3cMAn2JZRe0yI0l1NynT1rSyYefZWuw/ =3cUq -----END PGP SIGNATURE-----
