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. > > > 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
