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. 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. What is "now" by the way ... something in the MM tree? Or did that sneak in while I wasn't looking? - Dave - 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
