On Friday, 23 March 2007 18:57, David Brownell wrote: > On Friday 23 March 2007 6:43 am, Rafael J. Wysocki wrote: > > On Friday, 23 March 2007 00:55, David Brownell wrote: > > > > You said that if the hardware doesn't support a "turn CPU off" mode, then > > > you'd define that as being incapable of implementing suspend-to-RAM. > > > > That's _if_ the suspend-to-RAM is defined as the state in which the CPU > > is off, which I _think_ would be a reasonable definition. > > I disagree. Fine, this only is a matter of opinion. :-) > > I don't mean the > > platforms incapable of doing this should be restricted from entering any > > system-wide low-power states, but perhaps we can call these states > > differently. > > Well, we have ** ONLY TWO LABELS TO APPLY ** and you're saying that > one of them should be restricted to systems where the CPU can go into > an "off" state. As long as you insist on using two lables only and these two labels in particular, then fine. [Well, in such a case I'd change them to something different (like "suspend level 1", "suspend level 2").] Still, technically it doesn't really matter. What matters is that we need to tell drivers what we expect them to do with the devices when we're transitioning from one state to another system-wide. And that, IMO, should be defined. > > > That's a restriction ... a very arbitrary one. > > > > > My point is that _if_ we use lables like "standby", "STR", "STD", etc., > > That is, the strings in /sys/power/state. That's a given for now... Okay, I see your point now. > > then they shouldn't mean different things on different platforms. > > Unreasonable. The platforms are different. And moreover the > specifics DO NOT MATTER to userspace. Plus, they can differ > even on two x86 systems: different D-states, different wakeup > events. So nobody has any valid expectation that STR on one > box has exactly the same behavior on a different box. And if > users are trained to expect anything, it's that platforms will > differ in those details. > > > So, either > > we don't use labels at all, or we should know what they mean regardless > > of what platform we're talking about. > > 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 do you think the meaning of it can change from one platform to another? And if it can, how can the drivers figure out the meaning? Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
