On 05/14/2018 02:05 PM, Jean-Baptiste Maneyrol wrote:
The purpose of this series is to implement a new timestamping mechanism
able to cope with missing and delayed interrupts.
Since our system is not real-time, there will be cases where interrupts
with higher priorities will prevent the execution of our interrupt
handler. We need to be able to deal with it and keep an accurate
timestamp for data. We will not loose data since chips have a FIFO, but
we will loose interrupt timestamps.
The main idea in this mechanism is first to validate interrupt
timestamps, and then use them to estimate the chip internal clock from
system side. For validating an interrupt timestamp, we compute the delta
time between 2 interrupts and divide it by the chip divider to come back
to the chip internal 1KHz frequency. If the value matches 1KHz by +/-
4%, we consider it to be valid. In this case, we use the interrupt
timestamps for the data and the computed interval for estimating the
chip internal frequency (doing a mean with the precedent value for a
low-pass filtering). If the value doesn't match the 4% criteria, we drop
the timestamp and we compute a new one using the precedent value and the
estimated chip frequency.
The first patches of the series are some cleanup needed for this
implementation :
* patch 1: get rid of the timestamps FIFO (was in fact useless)
* patch 2: replace fifo rate in Hz by the sample rate divider needed by
the timestamp mechanism. Sample rate divider is equivalent to fifo rate.
* patch 3: fix fifo count reading by ignoring incomplete datum (can happen)
* patch 4: fix fifo overflowing by using more accurate int status bit
* patch 5: the new timestamp mechanism
Martin,
any feedback from your platform where the issue appears a lot are welcome.
Thanks.
JB
I like this approach. I tested the patch series on my troubled board and
am happy to report it working nicely.
Tested-by: Martin Kelly <mkelly@xxxxxxxx>
(for all the patches)
--
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
