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
sorry for the delay in responding
On Wed, 25 Jul 2007, Jerome Glisse wrote:
[EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Jerome Glisse wrote:
> On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > For instance on graphics card you could do the following (maybe
> > more):
> >
Hi!
> > let me give you a real world example then, and the numbers I'm using are
> > ballpark the same as you'll find in a (mobile) core 2 duo datasheet, I
> > just rounded them a little so that the math works out nice.
> >
> > power at full speed: 34W
> > power at half speed: 24W
> > power at id
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
[EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Jerome Glisse wrote:
On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
will each plugin have it's own interface? or will you have one
interface
to access the plugins and then the plugins do things behind the
scenes?
I'll bet that the A
On Wed, 25 Jul 2007, Jerome Glisse wrote:
On 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, 24 Jul 2007, Jerome Glisse wrote:
> On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Mon, 23 Jul 2007, Igor Stoppa wrote:
> > > again, HAL / OHM / Mobilin
> >
> >
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 7/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Tue, 24 Jul 2007, Jerome Glisse wrote:
> On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> On Mon, 23 Jul 2007, Igor Stoppa wrote:
>> > again, HAL / OHM / Mobilin
>>
>> I was trying to define the lower level interfaces that
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 Tue, 24 Jul 2007, Igor Stoppa wrote:
On Tue, 2007-07-24 at 10:43 +0200, ext Jerome Glisse wrote:
I believe a central place where user can set/change hw state to save
power or to increase computational power is definitely a goal to pursue.
But i truly think that the OHM approach is the best
On Tue, 24 Jul 2007, Jerome Glisse wrote:
On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Mon, 23 Jul 2007, Igor Stoppa wrote:
> again, HAL / OHM / Mobilin
I was trying to define the lower level interfaces that these tools need.
today they can only know what is possible by read
On Tue, 2007-07-24 at 10:43 +0200, ext Jerome Glisse wrote:
> I believe a central place where user can set/change hw state to save
> power or to increase computational power is definitely a goal to pursue.
> But i truly think that the OHM approach is the best one ie using plugins
> so that one can
On 7/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Mon, 23 Jul 2007, Igor Stoppa wrote:
> again, HAL / OHM / Mobilin
I was trying to define the lower level interfaces that these tools need.
today they can only know what is possible by reading the source code for
each driver and implemen
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 Mon, 23 Jul 2007, Arjan van de Ven wrote:
On Sun, 2007-07-22 at 22:25 -0700, [EMAIL PROTECTED] wrote:
only if the transitions don't cost anything significant,
these are second order effects though. On a pc, the transition costs are
quite low (as I said, single or low double digit microsec
On Mon, 23 Jul 2007, Igor Stoppa wrote:
On Sun, 2007-07-22 at 14:21 -0700, ext [EMAIL PROTECTED] wrote:
[snip]
this is another one. I'd be happy to get pointers to prior ones to learn
from.
https://lists.linux-foundation.org/pipermail/linux-pm/2007-March/011204.html
This is probably one of
On Mon, 23 Jul 2007, Ondrej Zajicek wrote:
On Sun, Jul 22, 2007 at 09:19:17PM -0700, Arjan van de Ven wrote:
let me give you a real world example then, and the numbers I'm using are
ballpark the same as you'll find in a (mobile) core 2 duo datasheet, I
just rounded them a little so that the mat
On Sun, 2007-07-22 at 22:25 -0700, [EMAIL PROTECTED] wrote:
> >>
> >> only if the transitions don't cost anything significant,
> >
> > these are second order effects though. On a pc, the transition costs are
> > quite low (as I said, single or low double digit microseconds).
>
> including pausing
On Sun, 2007-07-22 at 14:21 -0700, ext [EMAIL PROTECTED] wrote:
[snip]
> this is another one. I'd be happy to get pointers to prior ones to learn
> from.
https://lists.linux-foundation.org/pipermail/linux-pm/2007-March/011204.html
This is probably one of the latest. Previously there was some c
On Sun, Jul 22, 2007 at 09:19:17PM -0700, Arjan van de Ven wrote:
> let me give you a real world example then, and the numbers I'm using are
> ballpark the same as you'll find in a (mobile) core 2 duo datasheet, I
> just rounded them a little so that the math works out nice.
>
> power at full spee
On Sun, 22 Jul 2007, Arjan van de Ven wrote:
On Sun, 2007-07-22 at 21:04 -0700, [EMAIL PROTECTED] wrote:
this strategy should work well on the normal unpredictable workload that
most people deal with, but there are some cases where the workload becomes
pretty predictable (media players for exa
On Sun, 2007-07-22 at 21:04 -0700, [EMAIL PROTECTED] wrote:
> >> the fact that you want to run at the max frequancy for a given voltage is
> >
> > no I want to run at the max frequency PERIOD. On just about any PC, it's
> > more power efficient to go full speed when executing code, and then idle
>
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
On Sun, 22 Jul 2007, Arjan van de Ven wrote:
I disagree with you here. for each frequency setting you can say how much
power the cpu/system is expected to use (especially as a percentage of the
full power mode). creating this value requires you to take two things into
account, the voltage you ar
> 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
> I disagree with you here. for each frequency setting you can say how much
> power the cpu/system is expected to use (especially as a percentage of the
> full power mode). creating this value requires you to take two things into
> account, the voltage you are running things at (by far the bigg
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, 22 Jul 2007, Arjan van de Ven wrote:
son anyway)
I don't think you have got it right: the only info being passed is the
standard cpufreq list of frequencies; everything else is part of the
cpufreq driver.
to make the decisions the software makeing the decision needs to know how
much
> >> son anyway)
> >
> > I don't think you have got it right: the only info being passed is the
> > standard cpufreq list of frequencies; everything else is part of the
> > cpufreq driver.
>
> to make the decisions the software makeing the decision needs to know how
> much power would be used at
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, Igor Stoppa wrote:
On Sun, 2007-07-22 at 01:58 -0700, ext [EMAIL PROTECTED] wrote:
On Sun, 22 Jul 2007, Igor Stoppa wrote:
[snip]
Could you elaborate on how your proposal is incompatible with enhancing
the clock framework?
It's not that I think it's incompatible with
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
On Sun, 2007-07-22 at 01:58 -0700, ext [EMAIL PROTECTED] wrote:
> On Sun, 22 Jul 2007, Igor Stoppa wrote:
[snip]
> > Could you elaborate on how your proposal is incompatible with enhancing
> > the clock framework?
>
> It's not that I think it's incompatible with any existing powersaving
> tools
On Sun, 22 Jul 2007, Igor Stoppa wrote:
Hi,
On Sat, 2007-07-21 at 23:49 -0700, ext
[EMAIL PROTECTED] wrote:
I'm deliberatly breaking the threading on this so that people who have
tuned out the hibernation thread can take a look at this.
below is the proposal that I made at the bottom of one of
Hi,
On Sat, 2007-07-21 at 23:49 -0700, ext
[EMAIL PROTECTED] wrote:
> I'm deliberatly breaking the threading on this so that people who have
> tuned out the hibernation thread can take a look at this.
>
> below is the proposal that I made at the bottom of one of the posts on the
> hibernation th
I'm deliberatly breaking the threading on this so that people who have
tuned out the hibernation thread can take a look at this.
below is the proposal that I made at the bottom of one of the posts on the
hibernation thread.
the idea is that instead of approaching power management from the poi
40 matches
Mail list logo
