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 -- 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
