Subject: Re: PNP power management API for drivers
To: None <tech-kern@NetBSD.org>
From: Joerg Sonnenberger <email@example.com>
Date: 10/05/2007 23:23:55
On Fri, Oct 05, 2007 at 11:07:55PM +0200, Matthias Drochner wrote:
> firstname.lastname@example.org said:
> > bool pnp_device_register(dev_t, bool (*suspend)(dev_t),
> > bool (*resume)(dev_t));
> At a first glance, this looks pretty much like an oversimplification
> to me. The amount of device state to save or restore depends on
> bus specifics.
And this function is called from the bus frontend. There are few
examples of drivers that have only handlers in the backend code and that
isn't an issue either as the frontend can just use those as well.
> And it is not obvious what the sementics of "suspend"
> and "resume" are at all. Obviously, maximal power saving to prepare
> for laptop hibernation is a goal, but there is a lot in between --
> there are different levels of hibernation, and device/driver support
> is likely varying, so it needs some negotiation to get at least
> the "best effort".
I haven't seen any driver in the current tree that supports for then off
and on. For PCI devices, the power states all mean "doesn't initiate
transactions on the bus", which pretty much boils down to on/off from
the perspective of a driver. This is different from the perspective of
the bus. Putting a device in D1 and putting it in D3cold makes quite a
difference for the response time. But as I wrote in the note at the end,
this is something that will be extended later. Without some other parts
in the infrastructure (e.g. freza's soc code) this is pretty pointless
> When I played with USB power management a while ago I found
> that a device driver should support at least two more cases:
> -some notification that the device was selected as a possible
> source of a wakeup event, from toplevel to the driver, and
> from the driver upwards the bus hierarchy
This is orthogonal to the proposal at hand and I would strongly like to
defer this to a different point. I believe that this can be handled by
device properties without compromising the system.
> -some way for the driver to notify upper layers whether it is in
> use by some user application (or network connection, or disk
> mount, or whatever) so that some "best effort" power saving
> can be applied
This is generally handled by the device class or other means. It is
completely unrelated to the task of managing an individual device.
This proposal is not about power saving policies-- it is about providing
the means for a driver to implement the functionality needed for that.
About the name: the PNP term was coined by Jared and I am continuing to
use that for consistency.