I already mailed the following remark to Matthew and just reposting here because there might be common interest:
I get the sense that this is for common Intel-like ACPI-controlled
components, but have you seen the stuff Texas Instruments implemented in
the OMAP3430 embedded processor? I attended a demo of this at the CELF
embedded Linux conference in april and it was quite impressive, there is
a presentation here (powerpoint, not my fault): http://www.celinux.org/elc08_presentations/TI_OMAP3430_Li...
Page 19 is especially interesting: they have implemented C-states,
however these have platform-specific meanings:
C0 System executing code
C1 MPU WFI + Core active + No tick suppression
C2 MPU WFI + Core active + Tick suppression
C3 MPU CSWR + Core active + Tick suppression
C4 MPU OFF + Core active + Tick suppression
C5 MPU RET + Core RET + Tick suppression
C6 MPU OFF + Core RET + Tick suppression
C7 MPU OFF + Core OFF + Tick suppression
OFF is really OFF as in power disconnected. So this is how they address
submicron technologies with increased leakage.
On top of that all peripherals are already powered down when not used
(even for very very short intervals, ms range) this is called "OFF
mode".
This is so far ahead of anything I've seen on the desktop, laptop etc,
so I think it's interesting because that's where I think the common
equipment must be in just a few years.
Posted Dec 1, 2008 3:57 UTC (Mon) by HalfMoon (guest, #3211)
[Link]
OMAP processors come from cell phone designs, so they're pretty far ahead of what mainstream x86 processors -- or even SOCs -- do. They've got to stretch leetle tiny batteries out to a week of use. Accordingly they're pretty far ahead of most other embedded processors in terms of being optimized for low power consumptions.
One big hangup for Linux is that so much of the power management work has been revolving around ACPI ... which has a lot of fairly broken concepts in those very low power concepts. One of the biggest being that it even makes *sense* to need separate system states like "suspend to memory". Those OMAP designs more or less aim at having that be the default system idle state.
This isn't entirely unlike the OLPC model ... except OLPC was stuck with hardware designed to fit into an ACPI world, and which accordingly doesn't have good support for all that runtime power management. Devices tend to need long delays to get back to runnable states. The system doesn't really resume into a low power state, it resumes into a full power state and then -- if you're lucky! -- all the devices (and bridges etc) go into low power states right away
It'll take a long time for x86 system design methodologies to adapt to the models used in OMAP. If they even can. Intel's ATOM stuff isn't aiming to be that power-efficient, and I can't think of any other companies in the x86 space who have the technical and market power to change the game that much.