Re: [PATCH v3] imu: inv_mpu6050: interpolate missing timestamps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/26/2018 12:35 AM, Jean-Baptiste Maneyrol wrote:


On 25/04/2018 20:06, Martin Kelly wrote:
On 04/06/2018 09:33 AM, Martin Kelly wrote:
On 04/06/2018 08:41 AM, Jonathan Cameron wrote:


On 6 April 2018 16:21:05 BST, Jean-Baptiste Maneyrol <JManeyrol@xxxxxxxxxxxxxx> wrote:
Hello,


there is just a problem if I'm understanding well.


Reading FIFO count register under hard irq handler (when taking the
timestamp) is not possible since i2c access is using a mutex. That's
why we are using an irq thread for reading FIFO content.

Good point. Need more sleep or caffeine!



I was about to reply with the same, as I started coding it up :). Too bad, it was such a great plan!

I have a little update: When switching to level triggered interrupts, the problem goes away for me, as do the bus errors I get at high frequencies. I'm working on a patch to support other interrupt types than rising edge, which is almost done.

I also intend to look again at the bus errors for edge driven interrupts. Since they happen only at high frequency and go away with level driven interrupts (which must be acked and therefore prevent reentrancy), I suspect there's a concurrency bug.

That said, I think the question remains: Since we can't get the FIFO count from the hard IRQ handler, and since it could be some time before the bottom half thread is scheduled, I don't see any way to accurately handle forward interpolation.

Though we can't do forward interpolation, I think at least having backward interpolation is better than filling in blank timestamps, especially as we haven't seen an actual case of forward interpolation being needed, while we have real use cases that require backward interpolation (and can be easily verified in a logic analyzer).

However, that's only my opinion. Jonathan, Jean-Baptiste, and others, what do you think?


Hi,

What can I do to help get closure on this? Is there any data I could gather that would help make a decision?

In cases of a troubled system, I think the interpolation is very useful, and it's awkward to do in userspace, as it involves keeping a history of past records, which can be inconvenient and not always accurate (e.g. if userspace doesn't read fast enough and we miss records). However, I certainly understand the concern about interpolation. Should we consider making the interpolation configurable via sysfs or device-tree?

I'd be happy to hear other ideas too about better handling the case of missed interrupts.

Hello,

I have implemented a new timestamp mechanism that do something similar but in a more precise way.

The main ideas are:
* check if interrupt timestamp is valid (computes interrupt timestamps interval and check against set period value with a margin) * use validated interrupt timestamps to measure chip internal period from the system (to have more accurate computed timestamp value)
* use the interrupt timestamp for data if it is valid
* if interrupt timestamp is invalid (meaning interrupt was delayed or missing), computes timestamp using the measured chip period

I will send the corresponding patch series as soon as my last clean-up series has been accepted by Jonathan.

Regards,
JB

Excellent, I look forward to the patches. Jonathan, are you OK with this design approach?
--
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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux