On Monday 24 July 2006 7:51 am, Alan Stern wrote: > On Mon, 24 Jul 2006, Rafael J. Wysocki wrote: > > So, it looks like the core will only need to tell the driver to "resume" > > with the implicit "go directly to the saved state" meaning and the > > driver will actually decide what to do. > > And this implies that the meanings of the suspend() and resume() method > calls are different from what people might normally think. No ... > suspend() > doesn't really mean "Put your device into a low-power state"; it means > "The system is going into a suspend, so remember the device's current > power state and take whatever actions are appropriate". Which is exactly what it means today. > For example, if > the device is already in a low-power state then it might be appropriate to > do nothing at all. Ditto. > Likewise, resume() doesn't mean "Change your device to fully ON"; it means > "The system is waking up from a suspend, so put your device back into > whatever power state it was in before the suspend occurred". It means "put it back in a fully operational state". And whether that state is "full on", or one of the "runtime suspend" states, or whether it goes into "full on" and then automagically into a "runtime suspend", doesn't matter externally. And can't even be noticed without test setups measuring differential power usage between different configurations... > These meanings may not be entirely consistent with the way the PM core > works now, I don't believe any semantic change is being discussed here. > but to me they make more sense. To make the core consistent > with this approach wouldn't require much of a change. Basically we just > have to rip out all the stuff referring to dev->power.power_state, which > needs to be done anyway. Considering how few drivers use dev->power.power_state, it's easier to say the problem is in the ones that use it ... rather than the ones that ignore it and act as I've described above! :) - Dave > Alan Stern >
