On Sun, Jul 29, 2007 at 03:00:07PM -0700, [EMAIL PROTECTED] wrote:
> yes it is, and each type of device is growing it's own, incompatible,
> interfaces for controlling things like this. I was aiming to do two
> things.
Anything playing with power management needs to be aware of the
limitations
On Fri, 27 Jul 2007, Pavel Machek wrote:
Hi!
example 1: a laptop screen
mode capacity power description
000off
1 100 100full brightness
2 70 60half power to the backlight
3 50 35quarter power to the backlight
4 30
Hi!
> >>example 1: a laptop screen
> >>
> >>mode capacity power description
> >>000off
> >>1 100 100full brightness
> >>2 70 60half power to the backlight
> >>3 50 35quarter power to the backlight
> >>4 30 25eighth
On Tue, 2007-07-24 at 16:02 -0700, [EMAIL PROTECTED] wrote:
>
> what requirements are needed? (I'm sure that there are others, but
> hopefully it's possible to avoid requirements like 'the clock speed
> for
> device A must be >X to allow device B to operate in mode Y')
I had an idea a while ag
On Wed, 25 Jul 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote:
I think we need a set of constraints that trickle down the power
tree
and limit what a given driver can do locally.
what sort of contraints are you thinking of?
A parent power st
On Tue, 2007-07-24 at 13:14 -0700, [EMAIL PROTECTED] wrote:
> > I think we need a set of constraints that trickle down the power
> tree
> > and limit what a given driver can do locally.
>
> what sort of contraints are you thinking of?
A parent power state defines what states children can be in. F
On Tue, 24 Jul 2007, Benjamin Herrenschmidt wrote:
On Sun, 2007-07-22 at 10:26 -0700, Arjan van de Ven wrote:
On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] wrote:
this approach would allow the transition of ALL drivers to the new mode of
operation in one fell swoop, and then adding add
On Sun, 2007-07-22 at 10:26 -0700, Arjan van de Ven wrote:
> On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] wrote:
>
> > this approach would allow the transition of ALL drivers to the new mode of
> > operation in one fell swoop, and then adding additional power management
> > features is j
On Sun, 22 Jul 2007, Arjan van de Ven wrote:
Date: Sun, 22 Jul 2007 21:00:39 -0700
From: Arjan van de Ven <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: LKML ,
linux-pm <[EMAIL PROTECTED]>
Subject: Re: Power Management framework proposal
example 1: a laptop screen
mode ca
> example 1: a laptop screen
>
> mode capacity power description
> 000off
> 1 100 100full brightness
> 2 70 60half power to the backlight
> 3 50 35quarter power to the backlight
> 4 30 25eighth power to the backligh
On Sun, 22 Jul 2007, Arjan van de Ven wrote:
On Sun, 2007-07-22 at 11:56 -0700, [EMAIL PROTECTED] wrote:
I have a concern with this approach though. It seems to assume that
there is one global thing somewhere that sets the system state; in my
experience that is the wrong approach; in fact ther
On Sun, 2007-07-22 at 11:56 -0700, [EMAIL PROTECTED] wrote:
> >
> > I have a concern with this approach though. It seems to assume that
> > there is one global thing somewhere that sets the system state; in my
> > experience that is the wrong approach; in fact there is a very definite
> > evidence
On Sun, 22 Jul 2007, Arjan van de Ven wrote:
this approach would allow the transition of ALL drivers to the new mode of
operation in one fell swoop, and then adding additional power management
features is just adding to the existing list rather then implementing new
functions.
I have a concer
On Sat, 2007-07-21 at 23:49 -0700, [EMAIL PROTECTED] wrote:
> this approach would allow the transition of ALL drivers to the new mode of
> operation in one fell swoop, and then adding additional power management
> features is just adding to the existing list rather then implementing new
> funct
14 matches
Mail list logo
