Hi. On Mon, 2009-02-02 at 15:21 -0800, Arve Hjønnevåg wrote:> On Mon, Feb 2, 2009 at 1:47 PM, Nigel Cunningham> <ncunningham@xxxxxxxxxxx> wrote:> > It sounds to me like all of this stuff is just power management of> > individual devices, which should be done through the sysfs interface and> > completely unrelated to /sys/power/state.> > It is easier for us to add a hook to the individual drivers than to> maintain a list of devices in user-space. Also, last time I checked,> the only way to disable individual devices was through a deprecated> interface. Is there a new way to do this? Not as far as I know, but I understood that we weren't focusing on whatcurrently exists, but on what ought to exist to properly support whatyou're after, in a generic enough way to be useful to others as well. > > I'm putting the talk about> > suspending the CPU in this box too because it sounds like the desire is> > to stop the CPU without necessarily suspending other devices such as> > transmitters - sort of a CPU freq state where the frequency is 0.> > Is this different from idle? Well, I'm imagining a state that is more than just idle - where, as yousay, processes don't run until some sort of wakeup event occurs. > > That said, if suspend to ram is what they really want for 'auto-mem',> > what you're suggesting sounds good to me.> > Suspend gives us two advantages over idle. All threads are frozen> which means that an app that is using too much cpu time no longer> drains the battery. And, the monotonic clock stops. Do you want to leave any devices on while in this state? If not, okay -suspend to ram sounds right. If yes, I think you want to takeleave /sys/power/disk alone and go along the lines of run-time powermanagement instead. Regards, Nigel _______________________________________________linux-pm mailing listlinux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.linux-foundation.org/mailman/listinfo/linux-pm
