Re: [PATCH v5 1/2] iio:imu: inv_mpu6050: support more interrupt types

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

 



Hello,

I am now able to reproduce the issue by generating kernel irq (just plug/unplug mouse or keyboard is sufficient).

My last modification doesn't solve anything, since event the hard irq handler is disabled when processing another interrupt. Having a latched interrupt and triggering by level is a workaround, but clearly not perfect.

I think we need to work out a new solution for timestamping correctly the data.

JB


On 12/04/2018 20:16, Martin Kelly wrote:
On 04/12/2018 08:01 AM, Jean-Baptiste Maneyrol wrote:
Hello,

I've done further investigations on this issue, since I wasn't understanding why we were loosing interrupts where we shouldn't. And I think I found the root cause.

The irq handlers top and bottom are written in a way considering that every interrupt will be handled by the top part in the hard irq handler, even if the irq thread is still running in the bottom part. That's why we are using a FIFO for storing multiple timestamps.

But by using triggered-buffer setup, we are using the ONESHOT irq mode that is disabling irq until the thread processing is done. In this way, we are never reliably catching data interrupts when the thread is running, and there is no need to have a FIFO for storing timestamps.

The correct way would be to have the top part in the hard irq handler without using ONESHOT mode, and use only the thread for reading FIFO data in the triggered-buffer interrupt.

I have done a patch which is working correctly on my side. But since I am not able to trigger the issue in the first time, I cannot guarantee this is fixing the problem.

Martin,
is it possible for you to test the following patch and tell me if it is working better like that?

For sure, there is a conception issue here, because in the current setup having a FIFO for storing timestamps is completely useless.

JB


That's a good point, and sounds like a good change to me. Unfortunately it does not fix the issue I'm seeing, although I'm guessing it would improve it at high frequencies (though that's trickier to measure).

My issue is happening even at 10 Hz, in which the thread has ample time to complete before the next interrupt, so I think it's something related to the interrupt controller rather than this driver in particular.
--
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