Ikhwan Lee wrote: > Hi, > > On 3/15/07, David Brownell <david-b@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx >> https://lists.osdl.org/mailman/listinfo/linux-pm >> > _______________________________________________ > linux-pm mailing list > linux-pm@xxxxxxxxxxxxxx > https://lists.osdl.org/mailman/listinfo/linux-pm > _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/linux-pm
