Re: So, what's the status on the recent patches here?

Matthew Locke
2006-08-29T07:51:54Z

On Aug 28, 2006, at 10:39 AM, Pavel Machek wrote:

> On Mon 2006-08-28 09:40:38, Mark Gross wrote:
>> On Sat, Aug 26, 2006 at 03:46:53PM +0200, Pavel Machek wrote:
>>> On Sat 2006-08-26 17:30:40, Vitaly Wool wrote:
>>>> On 8/26/06, Pavel Machek <pavel@suse.cz> wrote:
>>> Because 8388608 policies is clearly not reasonable, powerop can not
>>> help here, and something better should be developed... like power
>>> domains someone proposed here.
>>>
>>> (Or to say it in another words, powerop forces one big power domain,
>>> which is bad model for notebook-style machine).
>>
>> I doubt notebook-style machines will ever us power op in any
>> significant way. HPC and embedded will be the first users.
>
> I agree here... power op look useless for notebooks. But I doubt power
> op authors would agree...

Agree that something I work on is useless? Never:) I know I sound like
a broken record but...

PowerOP is the basic building block for scaling power management. Its
as useless or useful as the cpufreq_driver layer of cpufreq is on
laptops. You can think of PowerOP as a redesign of cpufreq_driver that
enables other software in the PM stack to select a group of power
parameter values by a string. On x86 this other software can continue
to be cpufreq. On embedded devices the other software can use the
powerop sysfs api or kernel APIs.

>
>> Power domains will likely build on top power op.
>>
>> Power domains adds complexities themselves. Dealing with
>> dependencies and constraints between domains will be a challenge.
>
> Once we have power domains in/solved... do we still need power op? I
> thought power op could be useful for solving constrains _inside_ one
> domain, but...

I don't have a specific answer for this. We will deal with it when we
port to hardware that has power domain control.

> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>