[PATCH 0/5] iio: accel: adxl3xx: Add timestamps to FIFO data

Md Shofiqul Islam posted 5 patches 1 month ago
drivers/iio/accel/adxl313.h      |  4 ++++
drivers/iio/accel/adxl313_core.c |  8 ++++++--
drivers/iio/accel/adxl345_core.c | 12 ++++++++++--
drivers/iio/accel/adxl367.c      | 17 +++++++++++++----
drivers/iio/accel/adxl372.c      | 13 +++++++++++--
drivers/iio/accel/adxl380.c      | 15 ++++++++++++---
6 files changed, 56 insertions(+), 13 deletions(-)
[PATCH 0/5] iio: accel: adxl3xx: Add timestamps to FIFO data
Posted by Md Shofiqul Islam 1 month ago
Five ADXL-family accelerometer drivers (ADXL313, ADXL345, ADXL367,
ADXL372, ADXL380) push buffered samples using iio_push_to_buffers(),
which does not attach a hardware timestamp to the scan data.
Userspace consumers therefore receive samples with no timing
information.

This series adds timestamp support uniformly across the family:

  - A scan buffer struct with an aligned_s64 ts field is added to each
    driver's state struct.  The struct layout ensures the timestamp
    field sits at an 8-byte aligned offset as required by
    iio_push_to_buffers_with_timestamp().

  - In the FIFO push loop, FIFO data is copied into scan.channels via
    memcpy(), then iio_push_to_buffers_with_timestamp() is called with
    a single timestamp captured once per interrupt with
    iio_get_time_ns().  Using one timestamp per IRQ is consistent with
    the existing approach in the same handlers for event timestamps.

  - For ADXL367, the helper adxl367_push_fifo_data() gains a s64 ts
    parameter so the timestamp captured in the IRQ handler is passed
    through instead of calling iio_get_time_ns() a second time.

  - For ADXL372 and ADXL380, where the IRQ handler already called
    iio_get_time_ns() for the event push, the same captured timestamp
    is now also passed to the FIFO push, removing the duplicate call.

The ADXL313 and ADXL345 drivers always scan all three axes together
(available_scan_masks contains only the full X|Y|Z mask), so their
scan buffer layout is fixed.  The ADXL367, ADXL372, and ADXL380
drivers support variable scan masks; fifo_set_size tracks the number
of enabled channels per sample set and is used as the memcpy length.

Md Shofiqul Islam (5):
  iio: accel: adxl372: Add timestamp to FIFO data
  iio: accel: adxl380: Add timestamp to FIFO data
  iio: accel: adxl367: Add timestamp to FIFO data
  iio: accel: adxl313: Add timestamp to FIFO data
  iio: accel: adxl345: Add timestamp to FIFO data

 drivers/iio/accel/adxl313.h      |  4 ++++
 drivers/iio/accel/adxl313_core.c |  8 ++++++--
 drivers/iio/accel/adxl345_core.c | 12 ++++++++++--
 drivers/iio/accel/adxl367.c      | 17 +++++++++++++----
 drivers/iio/accel/adxl372.c      | 13 +++++++++++--
 drivers/iio/accel/adxl380.c      | 15 ++++++++++++---
 6 files changed, 56 insertions(+), 13 deletions(-)

-- 
2.54.0.windows.1
Re: [PATCH 0/5] iio: accel: adxl3xx: Add timestamps to FIFO data
Posted by Md Shofiqul Islam 4 weeks, 1 day ago
On Mon, 11 May 2026, Jonathan Cameron wrote:
> It is possible to approximate the correct timestamps but it's complex.
> You definitely don't want to try getting timestamps working for a fifo
> equipped part without real hardware so you can plot them over time and
> verify there are no inconsistencies or bugs in your timestamp
> approximation algorithm.

Understood -- thank you for the detailed explanation. I'll drop this
series. I don't have access to any of the ADXL hardware so I cannot
validate a per-sample timestamp approximation algorithm. I'll leave
this for someone with real devices to pick up when they are ready to
implement it properly, with the correct per-sample backfilling from
the FIFO watermark timestamp.

Thanks,
Shofiq
Re: [PATCH 0/5] iio: accel: adxl3xx: Add timestamps to FIFO data
Posted by Andy Shevchenko 1 month ago
On Sun, May 10, 2026 at 11:25:51AM +0300, Md Shofiqul Islam wrote:
> Five ADXL-family accelerometer drivers (ADXL313, ADXL345, ADXL367,
> ADXL372, ADXL380) push buffered samples using iio_push_to_buffers(),
> which does not attach a hardware timestamp to the scan data.
> Userspace consumers therefore receive samples with no timing
> information.
> 
> This series adds timestamp support uniformly across the family:
> 
>   - A scan buffer struct with an aligned_s64 ts field is added to each
>     driver's state struct.  The struct layout ensures the timestamp
>     field sits at an 8-byte aligned offset as required by
>     iio_push_to_buffers_with_timestamp().
> 
>   - In the FIFO push loop, FIFO data is copied into scan.channels via
>     memcpy(), then iio_push_to_buffers_with_timestamp() is called with
>     a single timestamp captured once per interrupt with
>     iio_get_time_ns().  Using one timestamp per IRQ is consistent with
>     the existing approach in the same handlers for event timestamps.
> 
>   - For ADXL367, the helper adxl367_push_fifo_data() gains a s64 ts
>     parameter so the timestamp captured in the IRQ handler is passed
>     through instead of calling iio_get_time_ns() a second time.
> 
>   - For ADXL372 and ADXL380, where the IRQ handler already called
>     iio_get_time_ns() for the event push, the same captured timestamp
>     is now also passed to the FIFO push, removing the duplicate call.
> 
> The ADXL313 and ADXL345 drivers always scan all three axes together
> (available_scan_masks contains only the full X|Y|Z mask), so their
> scan buffer layout is fixed.  The ADXL367, ADXL372, and ADXL380
> drivers support variable scan masks; fifo_set_size tracks the number
> of enabled channels per sample set and is used as the memcpy length.

This is sensitive change. Do we have any confirmation that this
- does work as expected on real HW and platforms that use these devices
- does not break any ABI

-- 
With Best Regards,
Andy Shevchenko