Hi Paul, On Monday 28 September 2015 10:05 PM, Paul Walmsley wrote: > On Thu, 24 Sep 2015, Lokesh Vutla wrote: > >> On Thursday 27 August 2015 09:51 AM, Lokesh Vutla wrote: >>> On Thursday 23 July 2015 06:55 PM, Lokesh Vutla wrote: >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
