Dear Lars-Peter, I am using iio_get_time_ns() to get the timestamp. The variation is big. For example, the frequency is 10Hz, which translates into 100ms per interrupt. However, I get something like 100, 100, 40, 160, 100, 100...... When a smaller timestamp happens, a big one follows to compensates it. So on average, it is hard to tell.. Only on per interrupt basis, you can tell it. While on an oscilloscope, I can see interrupts come at a very regular and precise pace. The hardware I am using Panda board. However, I don't think it is the hardware problem. The time function is updated via a timer interrupt. On a dual core system, it might be possible that one core cache get updated while the other is not. When interrupt happens, if the "wrong" CPU takes the interrupt, it might cause the problem. The iio_get_time_ns() is calling ktime_get_real_ts(), which calls getnstimeofday(). This function basically uses a static variable to get time. If the static variable is not updated, which could happen on an interrupt environment, and CPU is just using its cached version, it is quite possible that the data is wrong. Thanks. Best Regards, GE GAO -----Original Message----- From: Lars-Peter Clausen [mailto:lars@xxxxxxxxxx] Sent: Tuesday, February 05, 2013 2:01 AM To: Ge Gao Cc: Jonathan Cameron; linux-iio@xxxxxxxxxxxxxxx Subject: Re: [PATCH] [V9] Invensense MPU6050 Device Driver. On 02/05/2013 02:28 AM, Ge Gao wrote: > Dear Lars and Jonanthan, > I have one question regarding the timestamp inside IRQ. I found that > the timestamp taken during IRQ is not accurate and it varies a lot. I > can see the hardware interrupt came in a regular pace while the > timestamp taken varies violently(up to 50% or more). It seems that it > is because the data cache that stores the timestamp(xtime) is not > updated when there is interrupt. So it actually takes the wrong > timestamp. I searched online and didn't find any useful ideas. I think > taking timestamp during IRQ is a common practice. Is there any > existing solution for this or did I do anything wrong? The code in the > current patch is inv_mpu6050_irq_handler() of inv_mpu_ring.c. Thanks. What kind of time variation are we talking about? nanosecons, microseconds, milliseconds? iio_get_time_ns should query the systems clockchip and so the result should be pretty precise. - 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
