Subject: RFC: Device power management
To: None <tech-kern@NetBSD.org>
From: Jared D. McNeill <firstname.lastname@example.org>
Date: 07/15/2007 21:56:57
Heyas folks --
I've begun work on a device class-based power management framework. The
goals of this exercise are as follows:
1. Having a centralized policy for managing device power policies. As
each device class has different requirements, this framework manages
those interactions in a common way.
2. Turn off devices when not in use, and waking them when required.
3. Eventually, nuke the powerhook_establish/powerhook_disestablish
framework in favour of this new power handler API for purposes of
global system sleep.
Points 1 and 2 are the focus of my current work. I have implemented input,
audio, and display device class policies along with a sample power
management handler for the wskbd(4) driver (input class), azalia(4) (audio
class), and vesafb(4) (display class).
A bit of information about the different device class policies:
* Audio device class
Audio devices are transitioned to D0 state when opened. When the device
is opened but not in use (ie paused), it is transitioned to D1. Upon
closing the device, it is transitioned to D2, and after 30 seconds of
inactivity it is dropped further to D3.
A nice side-effect of implementing this in azalia(4) is that not only
does the device driver power itself down when not in use, but we also
know that the device driver is capable of bringing back the device from
cold; it should then "just work" as a global system sleep handler.
* Display device class
A simple inactivity policy, where the device state is gradually
transitioned between the following states over a period of inactivity:
* Input device class
Used to notify the display device class policy of activity.
I would appreciate input on reasonable policies for other device classes.
For point 3 above (which is not yet completed), we will require that all
active device instances have a valid power handler to enter system sleep.
The power management code responsible for putting the system to sleep will
disallow the sleep request if any single device on the system does not
implement a power handler. Likewise, any device driver may veto a sleep
request for any reason.