On Thursday 21 June 2007, Rafael J. Wysocki wrote:
> On Thursday, 21 June 2007 16:48, David Brownell wrote:
> > They really don't care what the state is. The $SUBJECT patch isn't
> > driver code ... it's for platform hooks that expose attributes to
> > the drivers. Specifically, it's ACPI code, talking to drivers that
> > must run on non-ACPI systems. Any driver that thinks it needs to
> > understand anything about ACPI states is sadly broken.
>
> But finally it has to place the device into a specific state and that state
> needs to be determined somehow.
I suppose I'm still thinking that the approach in my original
patch works Just Fine. Layering is kind of like this, going
from top to bottom (and omitting the go-to-pci-hardware stack,
and the initial ACPI pm hook before suspension starts):
PM infrastructure ... calling suspend() for everything
PCI bus support ... translates to PCI-specific typed call
PCI driver ... suspend() calling pci_choose_state()
ACPI support for PCI ... implementing choose_state()
ACPI core code ... remembering ACPI_STATE_Sx, calling AML
That is, ACPI gets invoked at various points, but the driver and
core code doesn't need to know ACPI from Rumpelstiltskin.
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
