David Brownell 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? they don't. and what is more important they wouldn't. Our idea is to provide building bricks: a clock provider node, a voltage provider node, a domain node, an arc of parent-child type, an arc of domain type, etc as well as tools/means (API) to construct an arbitrary graph from these nodes and arcs. These are pieces which parameter framework would bring to the plate. Further, an arch/platform system designer reading hw manual defines which nodes are required for a particular arch/platform and how a graph of nodes and arcs should look like for the arch/platform. Parameter framework API allows to build an arbitrary graph of nodes and arcs either statically or at runtime. This way a particular arch/platform graph configuration is the only arch dependent thing while the rest is handled in arch independent way. Am arch/platform designer uses only set of nodes and set of arcs required for his particular platform eliminating costs and complexity non-related to the specific platform. Of course, any generalization has size and performance penalties but with the proposed approach it's basically narrowed down to size of the structure representing a node in the tree and performance of tree traversing. Both leave opportunity for optimization without impact on generic ideas, structures and API though. 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
