On 08/04/2015 07:06 AM, Thomas Gleixner wrote:

On Tue, 4 Aug 2015, Grygorii Strashko wrote:

quoted

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.
 

quoted

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