Hi all,
DISCLAIMER: I'm new to kernel development.
I'm currently working on extending the kionix-kx022a driver to support
kionix-kx132. My question is about the timestamp pushed in the trigger
handler. The kionix-kx022a supports both FIFO and triggered buffer
mode, for my questions the triggered buffer mode is used.
Before asking the question: I tried to read every documentation
available, the kernel code and I found the Threads [1] [2] [3]
To better explain my question here are the two relevant setup functions:
A. devm_iio_triggered_buffer_setup_ext(dev, idev,
&iio_pollfunc_store_time,
kx022a_trigger_handler,
IIO_BUFFER_DIRECTION_IN,
&kx022a_buffer_ops,
kx022a_fifo_attributes)
B. devm_request_threaded_irq(data->dev, irq, kx022a_irq_handler,
&kx022a_irq_thread_handler,
IRQF_ONESHOT, name, idev);
And here are the relevant steps after an IRQ occurs :
1. IRQ context --> kx022a_irq_handler() --> gets the current timestamp
with "data->timestamp = iio_get_time_ns(idev);" and returns
IRQ_WAKE_THREAD
2. kx022a_irq_thread_handler() -> checks that the trigger is enabled
--> iio_trigger_poll_chained() --> handle_nested_irq(): which will only
call the bottom half of the pollfuncs
3. kx022a_trigger_handler() --> iio_push_to_buffers_with_timestamp(idev,
data->buffer, pf->timestamp)
My questions are:
Question 1: Is iio_push_to_buffers_with_timestamp(idev, data->buffer,
data->timestamp) instead of "pf->timestamp" better in the
trigger_handler ? I was first concerned that it would be racy with the
irq_handler, but the IRQF_ONESHOT flag is used, which means that the irq
line is disabled until the threaded handler has been run, i.e. until
kx022a_trigger_handler runs and retruns IRQ_HANDLED (right?).
Question 2: If the change proposed in question 1 is wrong, would this
one be better iio_push_to_buffers_with_timestamp(idev, data->buffer,
iio_get_time_ns(idev)). There is some delay between the IRQ occuring
and trigger_handler being called but that is better than getting all 0
timestamps like suggested in [2]
I hope that I'm understating this correctly or at least not totally
off :) If yes, I will send a patch.
[1] https://lore.kernel.org/linux-iio/4FDB33CD.2090805@xxxxxxxxxx/
[2] https://lore.kernel.org/linux-iio/20201205182659.7cd23d5b@archlinux/
[3] https://lore.kernel.org/linux-iio/20220126191606.00003f37@xxxxxxxxxx/
--
Kind Regards
Mehdi Djait
