On Sun, Feb 8, 2009 at 3:40 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Sunday 08 February 2009, Brian Swetland wrote: >> Out of curiosity, do these changes provide a model where the system can >> be in suspend 99+% of the time, waking up for specific events >> (voice/data telephony, user interaction, etc), and rapidly returning to >> suspend when the processing required is complete? > > The changes I was referring to above were rather related to the "normal" > suspend (ie. the one happening as a result of writing "mem" into > /sys/power/state). Namely, we believe that for some devices it is not > necessary or even desirable to allow the driver to perform all of the power > management operations by itself. For example, we are going to make the PCI > PM core (which in fact is the PCI bus type driver) handle the saving and > restoration of PCI devices' configuration registers as well as putting the > devices into low power states and back into the full power state. We can do > that, because in the "normal" suspend code path the suspend routines of a > driver are executed by the appropriate bus type's suspend routines and not > directly by the PM core. The "early suspend" mechanism seems to go round this > by calling directly into device drivers. How do you handle devices that should be in a low power mode when closed, and a high(er) power mode when open. While adding early-suspend hooks to a driver may be ugly, it does not need any more support than open and close does. > Also, please observe that if there is a mechanism allowing us to put individual > devices, or entire subsystems (such as a bus with devices attached to it), into > low power states at run time, without placing the entire system in a sleep > state, and put them back into the full power state as needed, we won't need > anything like the "early suspend" introduced by this series of patches. While early-suspend is not needed, it is still convenient on an embedded device where some drivers are clearly only used when the screen is on. > As far as the wakelocks are concerned, the goal they are designed to achieve is > quite simple: you want to prevent suspend from happening in certain situations. > In principle, one flag is sufficient for that. Still, there are many code > paths that might set and unset this flag and it would have been bad if the flag > had been set by one code path and then immediately unset by another one. > To prevent this from happening one can use a reference count with the rule that > suspend can only happen if it is equal to zero. We also want accountability. -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
