Subject: Re: PNP power management API for drivers
To: None <tech-kern@NetBSD.org>
From: Joerg Sonnenberger <email@example.com>
Date: 10/06/2007 04:20:02
On Fri, Oct 05, 2007 at 06:56:02PM -0700, Matt Thomas wrote:
> Again, for the TI OMAP 2430, bus structure has nothing to do with power
> domains. In fact, pretty much all devices live off the same bus but
> live in one of 5 power domains. So having a bus orientated handler
> isn't that helpful.
Let us ignore for a moment the the power domains. I'm using bus handler
purely in the sense of the logic view and the software interface. The
task of the bus handler is to deal with the common code that would have
to be duplicated across all drivers otherwise.
Consider the PCI case. You have to save and restore the PCI
configuration space (or at least 0x00 to 0x39). This can be done either
in all drivers (bad) or directly in the bus handler (good).
I expect the bus driver to be able to look up the power domain of a
specific device. Based on that it can power domain the device if all the
other components are suspended and resume them after the power has been
restored. This is an implementation detail of the bus though. I would
like to keep it as such if you can't present a strong case were device
drivers need to be exposed to this.
I want to keep this out because we have no good way to represent the
relation between devices right now. The device property code from freza@
is one possible representation and from that we can define the rest.
But to be able to make use of such information drivers have to support
at the very least suspend and resume. The goal here is to make the
driver side as easy as possible, simply because we have a lot more
drivers then anything else. Based on the work on the jmcneill-pm branch,
the proposed interface cuts down the work for network drivers by at
least half. Audio devices are a lot easier to handle now as well, even
though the infrastructure doesn't handle some parts yet. Isolating the
device parts and adding more handlers is a lot of work left, but both
the device classes and the bus drivers can be improved and the interface
refined without having to go through all that trouble again.