Scott E. Preece wrote:
> | From: Igor Stoppa<igor.stoppa@xxxxxxxxx>
> |
> | 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.
> ---
>
> If you did it this way:
>
> tid1 = power_transaction_start();
> clk_set_rate_pending(clk1, 300, tid1);
> clk_set_rate_pending(clk1, 600, tid1);
> power_transaction_commit(tid1);
>
> Then you can conveniently be constructing more than one transaction at a
> time and would have a little more information for debugging and for
> canceling partial transactions.
>
> I agree that there needs to be some use of hardware magic underneath to
> make the changes truly atomic; the flush/commit operation would have to
> use that magic.
i was talking about absolutely concrete example of SH7722 where you have 3
clocks managed via one register FRQCR. With this hw you:
1) have to keep predefined ratio between clocks like 1:n:n
2) can write the whole register at once (is it that hw magic you are talking about?)
So I want this hw to be supported by the framework. The transaction approach
pointed by Scott could be one of possible solution while I'd hardly accept
"anonymous" (not coupled with switching clocks) clk_rate_flush() approach.
Meanwhile we are proposing an alternative concept which completely hides such
clocks dependency inside the framework, behind the API: the dependency is coded
via clock tree structure (such clocks are linked with an arc), Further, assuming
clk_set() accepting variable number of clk_id/rate pairs as input parameters
such approach eliminates a need in adding transaction concept to the framework API.
The latter approach significantly simplify building group layer (operating
points) on top of parameter framework. Indeed, while with transaction approach
the knowledge of clocks dependencies in order to properly set up transactions
has to be exported to the group layer with our concept the group layer would be
as simple as mapping between a string name ("mp3") to single call to
clk_set_rate() (actually param_set()) where the whole list of parameters an
operating point is constructed from is passed to such a call.
> That has the advantage of putting all the complexity of
> undedstanding that magic in one place, at the cost of making that one
> place possibly arbitrarily complex.
yes, we are looking towards hiding this completely inside parameter framework.
Eugeny
>
> scott
>
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/linux-pm
