Nigel Cunningham wrote:
...
Two way communication between a userspace policy manager and kernel
drivers is implemented via DBus.
In this scheme, 'kernel drivers' doesn't just refer to the drivers for
hardware. It refers to anything remotely power management related,
including code to implement susp
Hi!
> > These are expected to be system states, and sleeping system
> > does not take calls, etc...
>
> Pavel, remember that great big "wakeup" shaped hole in the
> current PM framework... ? Even ACPI sleep states support
> wakeup mechanisms, although not well under Linux (yet).
Umm, yes, I see
On Thursday 03 March 2005 8:49 pm, Nigel Cunningham wrote:
> >
> > ... the goal of letting the system use those low
> > power modes more generally, without needing user(space) input to
> > suggest that now would be a good time to conserve more milliWatts.
> >
> > Of course, on systems that don't
Hi.
On Fri, 2005-03-04 at 13:17, David Brownell wrote:
> On Wednesday 02 March 2005 12:56 am, Pavel Machek wrote:
> >
> > If OMAP has "big sleep" and "deep sleep", why not simply map them to
> > "standby" and "suspend-to-ram"?
>
> Or even "cpu idle". Entering power saving modes shouldn't be suc
On Wednesday 02 March 2005 12:56 am, Pavel Machek wrote:
>
> If OMAP has "big sleep" and "deep sleep", why not simply map them to
> "standby" and "suspend-to-ram"?
Or even "cpu idle". Entering power saving modes shouldn't be such
a Big Deal. Some of the variable scheduling timeout work has been
Pavel Machek wrote:
...
In most of the cases I'm thinking of, it wouldn't be a user
requesting a state but rather software (say, a cell phone
progressively entering lower power states due to inactivity). I
haven't noticed a platform with more than 3 low-power modes so far,
Are not your power
On Thursday 03 March 2005 6:55 am, Pavel Machek wrote:
> Hi!
>
> > In most of the cases I'm thinking of, it wouldn't be a user
> > requesting a state but rather software (say, a cell phone
> > progressively entering lower power states due to inactivity). I
> > haven't noticed a platform with m
Hi!
> >...but adding new /sys/power/state might be okay. We should not have
> >introduced "standby" in the first place [but I guess it is not worth
> >removing now]. If something has more than 2 states (does user really
> >want to enter different states in different usage?), I guess we can
> >add
Pavel Machek wrote:
...
...but adding new /sys/power/state might be okay. We should not have
introduced "standby" in the first place [but I guess it is not worth
removing now]. If something has more than 2 states (does user really
want to enter different states in different usage?), I guess we can
Hi!
> >If OMAP has "big sleep" and "deep sleep", why not simply map them to
> >"standby" and "suspend-to-ram"?
>
> In fact that's more or less what happens (or will happen once drivers
> like USB stop looking for PM_SUSPEND_MEM, etc.). There are other
> platforms with more than 2 sleep states
Pavel Machek wrote:
Hi!
Advertise custom sets of system power states for non-ACPI systems.
Currently, /sys/power/state shows and accepts a static set of choices
that are not necessarily meaningful on all platforms (for example,
suspend-to-disk is an option even on diskless embedded systems, and th
Hi!
> Advertise custom sets of system power states for non-ACPI systems.
> Currently, /sys/power/state shows and accepts a static set of choices
> that are not necessarily meaningful on all platforms (for example,
> suspend-to-disk is an option even on diskless embedded systems, and the
> meaning
On Tue, 2005-03-01 at 18:03 -0800, Todd Poynor wrote:
> Advertise custom sets of system power states for non-ACPI systems.
> Currently, /sys/power/state shows and accepts a static set of choices
> that are not necessarily meaningful on all platforms (for example,
> suspend-to-disk is an option even
13 matches
Mail list logo
