On Thu, 2007-03-15 at 12:53 +0300, ext Eugeny S. Mints wrote: > 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) What's wrong with expanding the clk_fw? All is needed is: clk_set_rate_buffered(clk1, 300); clk_set_rate_buffered(clk2, 600); clk_rate_flush(); /* can include validation of the set */ Which is, incidentally, what OMAP2 does in hw for all the relevant clk dividers and it also provides validation for the new set of values. Furthermore if the original assumption that complex transitions are allowed only atomically (p1A, p1B) => (p2A, p2B), hw support is mandatory, otherwise the transition is impossible, no matter what fancy sw fw is performing it. > - 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) Is there any PLL which provide automatic switching between running/idle state? Do you have any HW architecture on your mind? > - current API does not provide support for clock domains So? > 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) that looks more like an optimisation to the clk fw, not a call for a brand new one > > > > > >> 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. relationships are very arch specific so having or not the fw there wouldn't probably make any real difference. About power domains ... well, what's the deal? Aren't they controlled like voltages, in the end? > > 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. I think what has to be clarified, is wether there is a real need for new features or not. > > > > 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. I think clocks and voltages providers have very different behaviours: for example a voltage src can sometimes be put in quiescent state, where the voltage value is preserved, but the max current is significantly reduced, therefore minimizing the leakage. I wouldn't welcome such functionality to be merged with clock handling. > > > > 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? I'd rather ask: what's the benefit of merging apples and oranges? > > > > 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 See my comment above about different, peculiar, behaviour of voltages. And that's just an example. > 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 -- Cheers, Igor Igor Stoppa <igor.stoppa@xxxxxxxxx> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/linux-pm
