On Saturday, 24 March 2007 01:01, Pavel Machek wrote: > Hi! > > (I do not want to get into this flamewar). I'd rather call it a misunderstanding. > > > That's a false choice, when you "mean" anything more than > > > fairly broad behavioral expectations: STR saves more power > > > than "standby", and transitions to/from STR take more > > > time than to/from "standby". > > > > So be it. > > > > Assume that the user does 'echo standby > /sys/power/state'. I think he can > > expect that in such a case we'll freeze tasks and put devices into low-power > > states and when he wakes up the system (BTW, I think the method of waking > > up can be treated as a differentiating factor) he should be able to continue > > from where he stopped after a little time. Fine. > > > > Now, we have to make that happen. After we have frozen tasks, we need to > > call something like device_suspend(some_argument) where the argument should > > tell drivers what to do. Say we use something like PMSG_STANDBY and now > > We would add another field to that struct, distingushing "mem" and > "standby". And meaning for the drivers would be "try to save a lot of > power, but keep the latency low" for standby, vs. "save as much power > as possible" for mem. Well, I think we can add more PMSG_* constants just fine. Still, for a driver, the meaning of PMSG_WHATEVER should be clear. I agree that whatever is done in pm_ops->enter(some_state) has to depend on the platform for quite obvious reasons, but the PMSG_* have some meaning beyond the platform-specific code. Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
