Hi all. I've been asked to do a talk at the CELF conference in a few weeks, on the topic of Linux 2.6 Power Management. As you all know, I'm more of a consumer than a producer, so I'd like to ask for your input. This should enable me to do a better job of portraying all the issues than I'd manage on my own. I promise I'll give credit! (I did suggest asking Patrick or Pavel, but for some reason, the CELF PM group thought to ask me first - and I'm going to visit Cyclades in Freemont anyway). Here's what I have so far... 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." The Outline To Date: ==================== 1) The overall aims of Power Management (No source here - feel free to add/blow away in flames) · Power saving · 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) 3) Past Implementations (2.4 - also cover earlier?) · APM support · Event notifier chains. · No STR. Suspend2 works, with some help from userspace. 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?) ACPI concerned with much more than just PM (Resource enumeration, IRQ routing, Sleep state enumeration/methods?) · Driver model implementation. Current focus more on system states (STR, STD). Run-time PM support not handled in driver model? · 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? Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574
