If there is other IRQ running causing this, the IRQ time would be late. However, this is not the case. I can see the time stamp value is smaller than it should be, while I observe from scope that IRQ comes in at a steady rate. Thanks. Ge -----Original Message----- From: Lars-Peter Clausen [mailto:lars@xxxxxxxxxx] Sent: Monday, March 31, 2014 12:07 PM To: Ge Gao Cc: Jonathan Cameron; linux-iio@xxxxxxxxxxxxxxx Subject: Re: unreliable time function inside IRQ? On 03/31/2014 07:44 PM, Ge Gao wrote: > Dear Jonathan, > Thanks for answering my question. I am using Panda board(OMAP4430). It is using a 32K counter clock as the high resolution clock(arch/arm/plat-omap/couter_32k.c). But I also observe the same thing in Nexus 7 first generation(announced in 2012), which uses Nvidia Tegra 3 platform. I suspect the data that represents the time is cached, or it is using some older value in the interrupt case. > It could be the Linux's time function problem. Is that possible? I actually tried using Jiffy, which is the built-in software clock. The time between each interrupt also varies big. My HZ setting is 1000. I also tried a later version of Linux, which is 3.7 or later. The result is the same. > The implementation of the time function is very simple. Below is the function from 32K clock counter. It is reading the hardware clock, compute the difference between a static variable and update the time. For a different clock, only the "clocksource_32k.mult", "clocksource_32k.shift", would be different. > Thanks. You have to consider that there will be other things running with IRQs off, which will cause some jitter for your IRQ handler. This is nothing IIO specific. - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
