This alternative "concept" would seem to be missing a few essential aspects. Like proposed interfaces, for starters ... On Wednesday 14 March 2007 3:43 am, Eugeny S. Mints wrote: > > > > Would this involve replacing the clock framework, or are they going to coexist? > > parameter framework would eventually replace clock framework. That seems to be the wrong answer. Especially since nothing has been shown to be wrong with the clock interface; much less to be unfixably wrong (hence justifying replacement). > Separate clock and > voltage frameworks lead to code and functionality duplication and do not address > such things as relationship between clocks and voltages, clock/voltage/power > domains, etc needed for aggressive power management. Most clocks don't have those issues. Why penalize all clocks for issues which only relate to a few? Better to only do that for the few cocks which have such additional constraints. Plus, remember that the clock framework is an interface ... so by definition, it has no code associated with it. Hence no duplication of code is possible... at least at this hand-wavey "concept" level. Possibly a given implementation has scope for code sharing; but I doubt it. Code behind a given implementation of the clock interface is invariably quite slim. If a clock being enabled implies a power or voltage domain being active, there's no reason that constraint shouldn't be enforced by whatever implementation a given platform uses. And having a generic -- basically untyped -- notion of "parameter" seems significantly less good than having a typed notion, with type-specific operations. Typed notions are easier to understand, read, and maintain. > Basically a good way of thinking about parameter framework is that parameter > framework would start from existed clock framework and gradually evolve by > addressing voltages, relationship between clocks and voltages, domains. > Eventually clock framework functionality would be a part of power parameter > framework. A better way would be to say that implementions of the clock interface on a given platform can build on whatever they need to build. That might include a "parameter" framework, if such a thing were defined in such a way that it became useful to such implementations. - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/linux-pm
