Re: Alternative Concept

["Eugeny S. Mints" <eugeny.mints@gmail.com>]

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