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

From: Matthew Locke <matthew.a.locke@comcast.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-pm@lists.osdl.org
Subject: Re: So, what's the status on the recent patches here?
Date: Tue, 29 Aug 2006 00:51:54 -0700	[thread overview]
Message-ID: <8f6ac3aac5268b8c03e7dafee7992bbe@comcast.net> (raw)
In-Reply-To: <20060828173957.GF30105@elf.ucw.cz>

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
>