David Brownell wrote: > This alternative "concept" would seem to be missing a few essential > aspects. Like proposed interfaces, for starters ... stay tuned - it follows ;) > > > 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). a cherry-picking on clk fw API: - clk_set_rate() sticks to an individual clock - no way to set rates for number of clocks at once instead of having series of clk_set_rate() calls. The former for example is required for clocks which have required predefined ratio dependency though: two clocks always have to be n:2n and any other ratio leads to hardware misbehavior. So, you can't go from 100:200 to 300:600 via series of clk_set_rate() for such clocks, i.e. 100:200 -> 300:200 -> 300:600 or 100:200 -> 100:600 -> 300:600 (see SH7722 hw for reference) - only a rate can be set up via clk_set_rate() while for a PLL I want to set up a desired idle state as well (btw there can be more than one idle state) - current API does not provide support for clock domains a cherry-picking on clk fw implementation: - clock tree structure and traversing clock tree code are duplicated in every architecture while can be done in arch independent way and just once (hint: what indeed is an arch specific thing it's a clock tree configuration) > > >> 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. parameter fw would give exactly this behavior: relationship between clocks and voltages, clock/voltage/power domains implementation would be just additional arcs between nodes for clock and voltages. Nowadays clk fw has only one type of arcs - parent-child type. parameter fw would bring additional types. But clock nodes would be linked just with required arcs (of required type; both are arch specific things) so for an arch without any additional dependencies between clocks (and voltages) parameter fw would end up with exactly equivalent clock tree as clk fw for the arch has today. > > 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. and invariably looks like a hack and still duplicate clock tree building and traversing code. Dependencies which exist in modern hw between clocks, clocks and voltages require a more straight and standard technique to be set up for implementing clk/vltg/name_it framework. Moving most of the code to be arch independent and setting a clear rules on how a clock/vltg tree configuration would look like while just looking at a hw manual would help. > > 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. true. but it's the same functionality required on different arches. and it can be done in arch independent way without penalties for arches which do not require the functionality. What's the rationale to move it down to arch specific code then? > > And having a generic -- basically untyped -- notion of "parameter" > seems significantly less good than having a typed notion, with > type-specific operations. there is no type-specific operations. clk_set_rate() and vltg_set() basically do the same thing - set a value for a pm resource provided by clock or voltage device (regulator). The difference is that output of clock regulator is measured in Hz and named 'frequesncy' and output of voltage regulator os measured in mV and named 'voltage' which actually does not matter from API POV. So, i see more sense in having param_set(), parame_set_state() (set_state primitive for idle states) rather than in clk_set_rate(), clk_set_state() vltg_set(), vltg_set_state() and, our analysis shows that you would end up with a separate type for domains, so it would be at least domain_set_state() as well. > Typed notions are easier to understand, > read, and maintain. common, after tricks with spinlocks in [merged!] RT patches? ;) Eugeny > > >> 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
