>I've been asked to do a talk at the CELF conference in a few weeks >The Brief: >========== >"Please present on the topic "Linux 2.6 Power Management". I have been >recommending to most people to use between 35 and 40 minutes for >presentation, and leave between 10 and 15 minutes for questions and >answers. I think that a general overview of the current directions in >power management infrastructure and technology for the 2.6 kernel would >be really great. >In the area of power management, we also have presentations on 1) >dynamic power management (power profile changes at high >frequency during >runtime) and 2) suspend/hibernate to flash. Your presentation is >currently scheduled for Wednesday, January 26th at 9:00 AM." Is flash on a CE device appear as a disk so that we'd use STD, or does it appear as RAM? >The Outline To Date: >==================== > >1) The overall aims of Power Management (No source here - feel free to >add/blow away in flames) >* Power saving ...without noticable performance impact. >* Quick return to usable state >* Flexibility - cope with variety of device capabilities, user policies >etc. >* Reliability >* Transparency to userspace (so far as possible) >* Good interaction with related functionality: hotplug. > >2) The Challenges in Power Management >* Documentation of device capabilities >* Devices don't always conform properly to standards (bugs) >* The complexity of the task - locking/ordering, minimising >invasiveness, interaction between drivers, provision of generic >functionality but also possibility of overriding, support of drivers >rejecting state changes. >- Interaction between run-time power management (driver sleeps when >nothing to do) and system states (suspend to ram/disk etc) At least on ACPI systems, one of the big challenges has been the breadth of interpretations of the ACPI spec. ie. fix one box, break another... >3) Past Implementations (2.4 - also cover earlier?) >* APM support >* Event notifier chains. >* No STR. Suspend2 works, with some help from userspace. 2.4 includes ACPI, including CPU power-state support. It also supports various P-state capabilities, though not as much as 2.6. We don't even try to support S3 (STR) in 2.4 though. > >4) The Current State of Play (2.6 kernel) >* Very much work in progress! >* Focus much more ACPI than now obsolete APM. (True of 2.4 too?) >From a Linux development point of view, this was true in 2.4 also. But this is because APM is BIOS-based and we're talking about OS development. With APM, the BIOS is in charge; with ACPI, the OS is in charge. Thus the development burden with ACPI is on the OS. >ACPI concerned with much more than just PM (Resource enumeration, IRQ >routing, Sleep state enumeration/methods...) For configuration, ACPI is somewhat of a catch-all HAL. Its goal is to abstract the hardware from the OS. Its goal is not to replace standard methods, but to provide a generic interface where standard methods do not exist. eg. PCI knows how to enumerate PCI devices -- ACPI is used to enumerate legacy devices. ACPI-based PCI-hotplug covers non-standard hot-plug controllers, but when PCI standardized its hot-plug controller, ACPI isn't needed for hot-plug where standard HW has shipped. I expect the same thing to happen with CPU, memory, and IO-hotplug -- they'll start off non-standard and abstracted by ACPI; and then later standard methods may emerge. >* Driver model implementation. Current focus more on system >states (STR, >STD). Run-time PM support not handled in driver model? cpufreq handles run-time PM for processors. Sometimes ACPI helps it, sometimes not -- depending on the processor and firmware. There is no run-time PM for devices -- and this is a gaping hole in Linux, along with the need for a place in the kernel where PM policy can be communicated from the user to the devices. >* Number of drivers still need switching to driver model or >implementation of suspend/resume methods. Particular problem areas USB >and DRI/DRM. >* Actual internal interface for device states still in a state of flux. > >5) Current working implementations: >* STR working on some x86, non-SMP systems >* STD (In kernel and Suspend2) work reliably on most x86 systems, ports >to PPC (both) and ARM (Suspend2 2.0). >* Runtime PM support via sysfs interface? > >6) The Future >* Stabilise internal API >* Completion of driver support for suspend/resume methods >* SMP, non-x86 support for STR. >* Improved support for other archs. >* Merge Suspend2? :> >* Improved runtime pm support? I think we're now in the "debug STR into existence" mode -- sort of like we were debugging ACPI interrupt configuration into existence a year ago. "existence" = something you can actually deploy and support. I think later this year we'll be spending significant time on what many consider the bottom line -- measuring and improving laptop battery life. -Len
