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
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
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 that
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
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
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
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
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
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 swap (or
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 something
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 more than
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 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
done
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
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
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 of
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
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 (say, XScale
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
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
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 on
25 matches
Mail list logo
