Hi! > 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) I'd add "it is not allowed to be intrusive". > 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. Actually biggest user of old pm_send() interface seems to be ALSA. > ? 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? It is not even clear what interface this should have. There's some completely unusable code in there already, but... > 6) The Future > ? Stabilise internal API Well, first step seems to be *) Fix internal APIs. Driver's suspend() method needs to get something else than u32. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
