On Wed, 2007-03-14 at 10:19 -0700, ext David Brownell wrote:
> 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).
I think the rationale for choosing to abstract a clock/voltage should be
clarified more.
> > 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.
Those that have such constraints tend to be very architecture dependant,
so that not much can be generalised or ported easily without having to add
too many levels of indirection.
> 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 that implementation could be highly optimised since it wouldn't care
too much about being portable.
> 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.
That sounds like being on the same lines of C vs C++ comments :) or why
not to use typedef struct foo {...} bar
>
> > 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.
>
But shouldn't it be useful on every platform? As a sort of resource
manager (because that's what it would become if it would start adressing
interdependencies between clocks and voltages).
--
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
