On 02/09/2016 09:52 PM, Lars-Peter Clausen wrote:
On 02/09/2016 12:06 PM, Gregor Boirie wrote:
To sump up, implementing timestamping clock selection support in IIO
should be based on the following principles.
Selected timestamping clock is a per-device attribute which the userspace
may access through a sysfs file.
It must be applicable to both buffered samples and events.
Just playing out ideas here to make sure we have everything covered, but
could be there be a setup where you'd want different timestamps for events
and buffers?
I'm not familiar enough with events to tell.
Userspace may choose amongst a subset of available POSIX clocks. A good
starting point would be: CLOCK_REALTIME, CLOCK_MONOTONIC,
CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE,
CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI.
Please delete as appropriate if needed and see clock_gettime(2).
One remaining question is : how do we ensure sample and event timestamps
consistency with respect to clock changes ? 2 suggestions:
* reject the ability to select a new clock as long as an events chardev is
opened
or a buffered samples channel is enabled ;
* clock may be changed at any time since it could be implemented in an atomic
way (a simple atomic_t can hold an int / clockid_t if I'm no wrong).
Not sure if we need to prevent it. If somebody changes it during an active
measurement it is their problem I'd say.
I like this way of keeping it simple. However, wouldn't this make the API
inhomogeneous ? After all, many channel related operations return
-EBUSY while flowing samples...
--
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
