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
[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 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 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 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:
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
> 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:
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, 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, 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
25 matches
Mail list logo
