Re: Alternative Concept

["Eugeny S. Mints" <eugeny.mints@gmail.com>]

Ikhwan Lee wrote:
> Hi,
> 
> On 3/15/07, David Brownell <david-b@pacbell.net> wrote:
>> On Wednesday 14 March 2007 3:08 pm, Scott E. Preece wrote:
>>> | >
>>> | > But shouldn't it be useful on every platform? ..
>>> |
>>> | I couldn't know.  This "alternative concept" hasn't gotten very far
>>> | into the hand-waving stage, much less beyond it into proposed interface
>>> | or (gasp!) implementations.  Platforms that don't *have* those particular
>>> | interdependencies should not of course incur costs to implement them...
>>> ---
>>>
>>> Well, that's fine if the platform you use is the current design
>>> center.
>> So you think that platforms which don't have such interdependencies
>> should incur costs and complexity to address problems they don't have.
>> Why?
> 
> Not every platform implements the clock interface. I think same can be
> done with the proposed power parameter framework. The basic codes
> defining the power parameter interface need not be costly and complex.
> 
> Since interdependencies significantly vary among platforms, we can
> leave that to platform specific code and have something as simple as
> the current clock interface for voltage and power domains.

exactly. I touched this already in reply to David. The interdependencies for a 
particular platform affect configuration of nodes and arcs graph only while do 
not affect the API. The graph configuration is the only arch dependent thing.

Eugeny

> 
>>> For the rest of us, though, all the stuff you're currently
>>> doing for power management is wasted effort and why should we incur
>>> costs to work around them?
>> Me personally?  What specifically are you referring to, and
>> in what respects would that be "wasted" effort?
>>
>>
>>> Today, we just configure it all out and put
>>> in our own stuff. We would prefer to have a mainstream framework that
>>> could be used to meet both Intel laptop needs and embedded device needs...
>> I don't think I ever said anything against that notion of having PM
>> infrastructure capable of handling both PC and embedded configs.  Not
>> that I've seen a framework that handles either one well -- yet! -- so
>> such notions haven't yet progressed to being testable theories.
>>
>> Against the notion of infrastructure (PM or otherwise) that's not
>> well designed or defined -- certainly I've argued.  That includes
>> much current PM infrastructure, and most recent proposals.
>>
>> - Dave
>> _______________________________________________
>> linux-pm mailing list
>> linux-pm@lists.osdl.org
>> https://lists.osdl.org/mailman/listinfo/linux-pm
>>
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>