On Thu, Jan 5, 2012 at 6:31 AM, Amit Kucheria [off-list ref] wrote:

Tiny, tiny typo...

On 11 Dec 13, Mike Turquette wrote:

quoted

+clk_set_rate deserves a special mention because it is more complex than
+the other operations. ?There are three key concepts to the common
+clk_set_rate implementation:
+
+1) recursively traversing up the clk tree and changing clk rates, one
+parent at a time, if each clk allows it
+2) failing to change rate if the clk is enabled and must only change
+rates while disabled
+3) using clk rate change notifiers to allow devices to handle dynamic
+rate changes for clks which do support changing rates while enabled
+
+For the simple, non-recursive case the call graph looks like:
+
+clk_set_rate(clk, rate);
+ ? ? __clk_set_rate(clk, rate);
+ ? ? ? ? ? ? clk->round_rate(clk, rate *parent_rate);

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^^^^^^

need a comma here? The next sentence kept me busy for 5 mins.

Thanks, will fix in next submission (along with general rework of
messy documentation).

Mike

quoted

+ ? ? ? ? ? ? clk->set_rate(clk, rate);
+
+You might be wondering what that third paramater in .round_rate is. ?If
+a clk supports the CLK_PARENT_SET_RATE flag then that enables it's
+hardware-specific .round_rate function to provide a new rate that the
+parent should transition to. ?For example, imagine a rate-adjustable clk
+A that is the parent of clk B, which has a fixed divider of 2.