On Saturday, 24 March 2007 04:08, Paul Mackerras wrote: > Rafael J. Wysocki writes: > > > > 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 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. > > My old powerbook 3400 has a "sleep" mode where the CPU is in sleep > mode, consuming very little power (and I suspect its clock is switched > off), the RAM is kept refreshed, most of the peripherals are switched > off (except that the video chip keeps its register settings), and > wakeup is under the control of the PMU (power management unit). > > My G4 powerbook has a "sleep" mode where the CPU is switched off, the > RAM is kept refreshed, most of the peripherals including the video > chip are switched off, and wakeup is under the control of the PMU. > > As far as a user is concerned, both machines are doing the same thing > - they're asleep. Tell me why we should draw a distinction at a > user-visible level between what these machines are doing, when there > is no user-visible difference in behaviour? What I have in mind is the level at which we pass some argument (eg. PMSG_SUSPEND) to a driver's .suspend() routine and this argument should depend on the low-power state we want to enter and the meaning of it for the driver should be exatly known. Greetings, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
