Patrick Mochel wrote: > - Automatic (or Dynamic) Suspend > > This is where a device will enter a low power state after a certain > amount of time has elapsed without any activity. > > The amount of time should be configurable on a per-device basis through > a sysfs interface. > > What defines "inactivity" is driver-dependent, and we expect to be > class-dependent (some classes may define inactivity as the device not > being opened; others may define it as having no read()/write() calls; > still others may define it as not having any network packets besides > ARP requests; you get the idea..) IOW, it doesn't matter to the core. > > The device should enter a low-power state that it supports. It doesn't > matter what state this is, and it's debatable whether or not it should > be exported/configurable via sysfs. (It's possible that a userspace- > based policy may wish to adjust this based on its extra knowledge about > system features/bugs, or based on the desired latency/consumption > tradeoff for the particular system or configuration (plugged, unplugged, > etc). > The device must be powered back on when a new request comes in. Again, > whether this is on open(), read(), or socket() is up to the class and > the drivers of that class. > > - Directed Suspend > > This where a user or an application specifies a device to enter a lower > power state. > > The states that a device exports (allows to be set) should be exported. > The application should specify which state to enter. > > By default, the device may not respond to I/O requests. There must be a > flag exported to control this. > > - Performance > > (This was not covered in detail, but based on the specified interface > above, it's pretty easy.) > > The states a device (and its driver) support should be exported via > sysfs. > > A user or application specifies which state to enter. > > This may turn on/off different functional components of the device. The > drivers need to be prepared to handle that. > As you hint on, there is a question of the interface between a policy manager and the devices. Many embedded devices need to aggressively manage power, so need to have an interface that allows device specific monitoring and control, yet for an average system a more generic policy manager included in a vendor's distribution could provide usable PM on a range of systems through a generic interface. So a question is how to support this. I suppose the PM system could allow both system specific interfaces and a 'generic standard' interface to be exported, with some mapping between. -Geoff
