From: Lars-Peter Clausen <lars@metafoo.de>
To: Ge Gao <ggao@invensense.com>
Cc: Jonathan Cameron <jic23@kernel.org>, linux-iio@vger.kernel.org
Subject: Re: [PATCH] [V9] Invensense MPU6050 Device Driver.
Date: Tue, 05 Feb 2013 20:47:38 +0100 [thread overview]
Message-ID: <511161DA.1020607@metafoo.de> (raw)
In-Reply-To: <5f06a44b95d69cb71424a59ce4f461f2@mail.gmail.com>
Hi,
On 02/05/2013 07:36 PM, Ge Gao wrote:
> 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.
Hm, this looks a bit odd indeed. Do you have other drivers active which could
be running code with interrupts disabled (e.g. their interrupt handlers) and be
delaying your interrupt handler?
> 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.
If you take a look at getnstimeofday() carefully you'll see that it will also
call timekeeping_get_ns() which again queries the hardware directly and adds
the difference between the hardware timestamp and the timestamp when the static
variable was updated to the result, so it should be pretty precise. Or maybe
your hardware source is so imprecise, but I doubt it.
- Lars
>
> Best Regards,
>
> GE GAO
>
> -----Original Message-----
> From: Lars-Peter Clausen [mailto:lars@metafoo.de]
> Sent: Tuesday, February 05, 2013 2:01 AM
> To: Ge Gao
> Cc: Jonathan Cameron; linux-iio@vger.kernel.org
> 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
next prev parent reply other threads:[~2013-02-05 19:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-02 0:26 [PATCH] [V9] Invensense MPU6050 Device Driver Ge GAO
2013-02-03 15:51 ` Jonathan Cameron
2013-02-04 18:46 ` Ge Gao
[not found] ` <2b0b8fba-fc2c-44fb-9512-d86e87b698c1@email.android.com>
2013-02-04 20:12 ` Lars-Peter Clausen
2013-02-05 1:28 ` Ge Gao
2013-02-05 10:00 ` Lars-Peter Clausen
2013-02-05 18:36 ` Ge Gao
2013-02-05 19:47 ` Lars-Peter Clausen [this message]
2013-02-06 3:41 ` Lars-Peter Clausen
2013-02-10 17:30 ` Lars-Peter Clausen
2013-02-10 17:45 ` Jonathan Cameron
2013-02-11 18:07 ` Ge Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=511161DA.1020607@metafoo.de \
--to=lars@metafoo.de \
--cc=ggao@invensense.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.