lkml.org 
[lkml]   [2007]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-pm] Power Management framework proposal
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 one ie using plugins
>> so that one can make a plugin specific for each device. The point is that
>> i believe there is no way to do an abstract interface for this and trying to
>> do so will endup doing ugly code and any interface would fail to encompass
>> all possible tweak that might exist for all devices.
>>
>> For instance on graphics card you could do the following (maybe more):
>> -change GPU clock
>> -change memory clock
>> -disable part of engine
>> -disable unit
>> i truly don't think you can make a common interface for all this, more
>> over there might be constraint on how you can change things (GPU &
>> memory clock might need to follow a given ratio). So you definitely
>> need knowledge in the user space program to handle this.
>
> Even simpler case: LCD backlight can come in many flavors, both in terms
> of brightness levels and fixed amount of current required to keep it ON.
>
> Trying to abstract such details from the decision-making makes little
> sense.
> Isolating that into a separate module, instead, brings the best of both
> worlds:
> -containment of the HW-specific code
> -leveraging every possible, no matter how exotic, power saving mode
> available.

huh??

in the proposal that I made all the HW specific code would be in the
device driver. I was just proposing a way for the driver to advertise what
it is able to do.

why would you want to pull the code out into a seperate model?

many levels of backlight with different power consumption is trivial to
do.

backlight 1

mode %capability %power
aka brightness
0 0 0
1 100 100
2 75 75
3 50 50
4 25 25

backlight 2

mode %capability %power
aka brightness
0 0 0
1 100 100
2 80 50
3 60 30
3 40 20
4 25 15

backlight 2

mode %capability %power
aka brightness
0 0 0
1 100 100
2 50 90


why do you think the decision makeing logic needs to know the details of
the hardware? if you can abstract the details out then the same control
logic can be used for different things. if you infuse the hardware
knowledge with the control logic then you have to change the control
section every time you want to support a new piece of hardware.

David Lang


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-24 22:19    [W:0.136 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site