Hi Paul,

On Monday 28 September 2015 10:05 PM, Paul Walmsley wrote:

On Thu, 24 Sep 2015, Lokesh Vutla wrote:

quoted

On Thursday 27 August 2015 09:51 AM, Lokesh Vutla wrote:

quoted

On Thursday 23 July 2015 06:55 PM, Lokesh Vutla wrote:

quoted

This series implements lock and unlock functions for RTC and hooks
the same to DRA7 and AMx3xx hwmod.
This is dependent on the patch https://patchwork.kernel.org/patch/6578281/,
which is queued recently by Paul.

Gentle ping on this series.

Do you have any comments on this series?

Looks pretty good.  I'm slightly concerned about the latency jitter impact 
on -rt kernels for that local_irq_disable() section.  Looks like it could 
hold off interrupts for ~(50 udelay ?s) + 50*((RTC register read time) + 
1).  But I'm not sure if preempt_enable/disable() is a good alternative 
since a bunch of interrupt top halves could conceivably run after the RTC 
goes non-busy and result in the RTC not being locked/unlocked. 

Agree.

Is there an RTC IP block register that the code can read, or a safe 
sequence that the code can execute, after the RTC lock/unlock operation to 
verify that the RTC has successfully been locked or unlocked?  If so then 
it's probably worth converting the local_irq_disable/enable() to 
preempt_disable/enable() and testing that, then retrying the lock/unlock 
if it fails.

I am afraid there is no such register to verify lock or unlock. Also
these KICK registers are Write only registers so can't read back the
value. Even the driver implement the same api's for writing into registers.

One thing I can think of is that to write a known pattern to scratch pad
register and read back the value to confirm if it is locked/unlocked.
But don't think this is a good approach.

Thanks and regards,
Lokesh