Re: [PATCH 05/13] PM: Add option to disable /sys/power/state interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 09 February 2009, Alan Stern wrote:
> On Sun, 8 Feb 2009, Arve Hjønnevåg wrote:
> 
> > How do you handle devices that should be in a low power mode when
> > closed, and a high(er) power mode when open. While adding
> > early-suspend hooks to a driver may be ugly, it does not need any more
> > support than open and close does.
> 
> This illustrates some of the problems of differing outlooks.  In an 
> embedded system, the set of devices is limited and the set of available 
> power states is known beforehand.  In other settings neither of these 
> is true.
> 
> Early-suspend is an example of a partially-functional system state.  
> In your Android-centric approach, early-suspend is centered around the 
> screen.  But other sorts of systems way well have other requirements 
> and may want their partially-functional system state to be centered 
> around something else.  Or they may want to have more than one 
> partially-functional system state.
> 
> What we need is a mechanism capable of accomodating all these different
> requirements.  Presumably the core kernel would provide the hooks but
> the implementation details would be left up to platform-specific code.  
> There should be a generic scheme for representing partially-functional
> system states, together with a list of devices to be put in low-power
> mode for each state and an indication of which low-power mode to use
> (since a device can have more than one low-power mode).  Device drivers
> should have an interface for going into a particular low-power state.
> 
> The extent to which all of this needs to be split between the kernel
> and userspace isn't immediately clear.  Latency issues might force a
> large part of it to live in the kernel.  On the other hand, if the list
> of devices & modes can be pushed out to userspace, then the in-kernel
> portion could end up being nothing more than a runtime-PM mechanism of
> the sort we have been discussing for years.

Agreed.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux