Hi Len. Thanks for your reply. On Thu, 2005-01-06 at 17:48, Brown, Len wrote: > >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? As a disk, I believe. I'm still getting familiar with embdedded technology, but on our (Cyclades) boxes, I'm almost certain the flash appears as a filesystem. > >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. Good point. Thanks. > >* 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... Mmm. We've seen that a lot. > >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. Thanks for the clarification - it was one of those slap forehead/oh I knew that moments :> > >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. 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. So how does ACPI know which pieces of hardware it needs to initialise/handle, and which are handled by the PCI-hotplug code? > 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. Thought of cpufreq only briefly :> It's my bias, I guess. > 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. Right. And this is what we've begun to discuss within the last few weeks, IIRC. > >* 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. Thanks again Len. Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574
