Hi All, On 08/04/2015 06:36 PM, Russell King - ARM Linux wrote: > On Tue, Aug 04, 2015 at 10:23:31AM -0500, Nishanth Menon wrote: >> Consider clk_enable/disable/set_parent/setfreq operations. none of these >> operations are "atomic" from hardware point of view. instead, they are a >> set of steps which culminates to moving from state A to state B of the >> clock tree configuration. > > There's a world of difference between clk_enable()/clk_disable() and > the rest of the clk API. > > clk_enable()/clk_disable() _should_ be callable from any context, since > you may need to enable or disable a clock from any context. The remainder > of the clk API is callable only from contexts where sleeping is permissible. > > The reason we have this split is because clk_enable()/clk_disable() have > historically been used in interrupt handlers, and they're specifically > not supposed to impose big delays. > > Things like waiting for a PLL to re-lock is time-consuming, so it's not > something I'd expect to see behind a clk_enable() implementation (the > fact you can't sleep in there is a big hint.) Such waits should be in > the clk_prepare() stage instead. > > Now, as for clk_enable() being interrupted - if clk_enable() is interrupted > and another clk_enable() comes along for the same clock, that second > clk_enable() should not return until the clock has actually been enabled, > and it's up to the implementation to decode how to achieve that. If that > means a RT implementation using a raw spinlock, then that's one option > (which basically would have the side effect of blocking until the preempted > clk_enable() finishes its business.) Alternatively, if we can preempt > inside clk_enable(), then the clk_enable() implementation should be written > to cope with that (eg, by the second clk_enable() fiddling with the hardware, > and the first thread noticing that it has nothing to do.) > Thanks a lot for your comments and explanations. Now lock object in CCF is not a raw spinlock, so, seems, I have to update code and try to move clk_enable()/clk_disable() out of atomic context. -- regards, -grygorii -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
