On Thursday, 21 June 2007 22:32, David Brownell wrote: > On Thursday 21 June 2007, Rafael J. Wysocki wrote: > > > platform->lowest_power_state_the_device_can_be_in(dev, wakeup) > > > > and > > > > platform->highest_power_state_the_device_can_be_in(dev) > > > > where 'wakeup' tells the platform whether we want this device to be able to > > wake up the system. > > That won't work well except with ACPI, since few systems centralize > that knowledge. Like ACPI does with AML ... but mostly for PCI. > > Look at your average SOC chip spec and you'll see a lot of information > that lives most naturally in the device drivers, or sometimes in the > clock framework. > > > > > pm_ops->prepare() is now called after the drivers' .suspend() routines have > > been executed, so the ACPI core, for example, has no means of learning what > > the next system state will be until all devices have been suspended. > > Well that's a design mistake. pm_ops->prepare() has to be called after device_suspend() for other reasons. > Remember that those suspend() methods > need to know the target system states, so that they can call the right > "_SxD" and "_SxW" methods. There needs to be *SOME* call into the > platform code that can be used to track "x" for ACPI ... or whatever > is needed on other platforms. YES! And that's what I'm asking about: How are we going to handle that? > What is "now" by the way ... something in the MM tree? Or did that > sneak in while I wasn't looking? 2.6.22-rc5 actually, and the patch was from Linus himself, acked by Len. ;-) 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
