[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <cover.1468203399.git.amsfield22@gmail.com>
Date: Mon, 11 Jul 2016 08:24:12 -0700
From: Alison Schofield <amsfield22@...il.com>
To: jic23@...nel.org
Cc: tiberiu.a.breana@...el.com, mranostay@...il.com, knaack.h@....de,
lars@...afoo.de, pmeerw@...erw.net, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: [PATCH 0/3] iio: complete the setup of buffer timestamps
These drivers are using iio_poll_func->timestamp in their triggered buffer
handler as the timestamp pushed to buffer. Problem is that it was not set up
at probe time via iio_triggered_buffer_setup(), so timestamp is always 0.
Buffer space has been allocated for the timestamp, so it seems to be
wanted.
These patches make the fix io_triggered_buffer_setup() during probe by
passing the iio_pollfunc_store_time parameter.
Alternative change would be to use iio_get_time_ns() directly in the
push_to_buffers call in the handler. We can do this if you are not
one of those "devices (who) need a timestamp grabbed as soon as possible
after the trigger" (from iio_poll_func definition)
Either way you are using iio_get_tme_ns(), it's just a question of when.
Let me know if you'd rather go the slower way.
Alison Schofield (3):
iio: accel: bma220_spi: set up buffer timestamps for non-zero values
iio: humidity: am2315: set up buffer timestamps for non-zero values
iio: proximity: as3935: set up buffer timestamps for non-zero values
drivers/iio/accel/bma220_spi.c | 2 +-
drivers/iio/humidity/am2315.c | 2 +-
drivers/iio/proximity/as3935.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--
2.1.4
Powered by blists - more mailing lists