On Sunday, 24 June 2007 01:46, Alan Stern wrote: > On Sun, 24 Jun 2007, Rafael J. Wysocki wrote: > > > Hi, > > > > The appended patch adds the new pm_ops callback to be used to pass the target > > system sleep state to the platform core (ACPI core in particular) and reworks > > the ACPI PM operations to take this callback into account. > > > > When I was working on this patch I thought it might be a good idea to do the > > following additional changes: > > * rename pm_ops to something more descriptive, like for example > > 'platform_suspend_operations' > > * move the definition of pm_ops (or whatever it will be called) to > > <linux/suspend.h> > > * make the prepare(), enter() and finish() callbacks not take any arguments > > * clean up the PM-related code in the ARM tree (that, and the previous one, > > would require someone to test the changes on these platforms, though) > > > > Comments welcome. > > Is this design okay with system states in which the CPU is able to run? Do you mean the patch or the suggestions above? > Right now the states we have are On, Standby, and Suspend, and the CPU > runs only in the On state. But on some platforms there could be > multiple states in which the CPU is able to run, albeit with degraded > performance. I wouldn't call those system sleep states. For example, ACPI defines system sleep states as the states in which no instructions are executed by any CPUs and I think that's reasonable. Moreover, the ACPI spec insists that transitions between different sleep states should be made through the On state. > So for something like Suspend the PM core tells the platform to enter > the new state, and when the call returns the system has already left > that state. But with a low-performance On state, when the call returns > the system will still be in the new state. > > Is the PM core prepared to handle this difference? No, I don't think so. IMO, runtime power management is needed for the low-performance On states. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
