| |||||||||||||
|
| |||||||||||||
Observations on (OMAP) power managementObservations on (OMAP) power managementPosted Dec 1, 2008 3:57 UTC (Mon) by HalfMoon (guest, #3211)In reply to: Observations on power management by linusw Parent article: Observations on power management
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.
(Log in to post comments)
|
|
||||||||||||