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 devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
