On 08/04/2015 07:06 AM, Thomas Gleixner wrote: > On Tue, 4 Aug 2015, Grygorii Strashko wrote: > >> Hi All, >> >> I'd very appreciated if someone can clarify one point for me. >> >> Is allowed/expected/prohibited to use CLK API like clk_enable/disable >> in atomic context now on RT-Kernel (HW IRQ or under RAW spinlocks)? > > It's not possible, if the spinlock in the clock framework is not a raw > spinlock. > >> How safe is it to allow CLK API to be preemptive? > > The functions are protected by the locks. So it's not an issue at all. interesting topic, looping in linux-clk. original thread in [1]. clk apis are protected by spinlocks which in turn should make the clock apis pre-emptible in RT kernel build. I think Grygorii's question is "what happens(is it safe) when clock APIs are pre-empted"? I think it is a bit dependent on the hardware behavior I think.. Two angles to this: i) is there an upper time bound in the programming sequence: if any step x to step y in the sequence takes more than N time, then we can have a failure - but then, that is a broken hardware in itself.. Linux (non-RT) cannot guarantee a strict upper bound either. ii) if by preempting the operation itself CPU cannot guarantee time accuracy for scheduling. This can be an issue. more below: 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. specific example could be as follows: changing clock parent in the clock tree results in kernel tick timer configuration to be in an intermediate state before going to a final "relocked" state which is expected at the end of clock setparent call, could be involved in a few steps: step a) unlock pll (put in bypass) step b) change parent step c) relock pll with new parent frequency if interrupted between (a), (c), we could be in "bypass" frequency or "new parent" frequency... final frequency is guarenteed only when step (c) is completed. In the above example if the clock generated is fundamental to kernel scheduler accuracy, well, we do have a problem.. I am not sure any of these cases can happen could happen in at least the hardware I am aware of... not sure if other SoC vendors might have interesting scenarios.. [1] http://marc.info/?t=143868984600001&r=1&w=2 -- Regards, Nishanth Menon -- 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
