On Thursday, 21 June 2007 22:22, David Brownell wrote: > 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):
We're missing that hook right now. ;-) > 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. I agree with that, but we need to add a mechanism to tell the ACPI core what it needs to know (ie. the target system sleep state) before we suspend devices or while we are suspending them. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - 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
