On Sun, 8 Feb 2009, Arve Hjønnevåg wrote: > 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. This illustrates some of the problems of differing outlooks. In an embedded system, the set of devices is limited and the set of available power states is known beforehand. In other settings neither of these is true. Early-suspend is an example of a partially-functional system state. In your Android-centric approach, early-suspend is centered around the screen. But other sorts of systems way well have other requirements and may want their partially-functional system state to be centered around something else. Or they may want to have more than one partially-functional system state. What we need is a mechanism capable of accomodating all these different requirements. Presumably the core kernel would provide the hooks but the implementation details would be left up to platform-specific code. There should be a generic scheme for representing partially-functional system states, together with a list of devices to be put in low-power mode for each state and an indication of which low-power mode to use (since a device can have more than one low-power mode). Device drivers should have an interface for going into a particular low-power state. The extent to which all of this needs to be split between the kernel and userspace isn't immediately clear. Latency issues might force a large part of it to live in the kernel. On the other hand, if the list of devices & modes can be pushed out to userspace, then the in-kernel portion could end up being nothing more than a runtime-PM mechanism of the sort we have been discussing for years. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
