Linus Walleij [off-list ref] writes:

On Thu, Feb 27, 2020 at 12:06 AM Thomas Gleixner [off-list ref] wrote:

quoted

"Christopher S. Hall" [off-list ref] writes:

IIO has a config file in sysfs that lets them select the source of the
timestamp like so (drivers/iio/industrialio-core.c):

s64 iio_get_time_ns(const struct iio_dev *indio_dev)
{
        struct timespec64 tp;

        switch (iio_device_get_clock(indio_dev)) {
        case CLOCK_REALTIME:
                return ktime_get_real_ns();
        case CLOCK_MONOTONIC:
                return ktime_get_ns();
        case CLOCK_MONOTONIC_RAW:
                return ktime_get_raw_ns();
        case CLOCK_REALTIME_COARSE:
                return ktime_to_ns(ktime_get_coarse_real());
        case CLOCK_MONOTONIC_COARSE:
                ktime_get_coarse_ts64(&tp);
                return timespec64_to_ns(&tp);
        case CLOCK_BOOTTIME:
                return ktime_get_boottime_ns();
        case CLOCK_TAI:
                return ktime_get_clocktai_ns();
        default:
                BUG();
        }
}

That's a nice example of overengineering :)

After discussion with Arnd we concluded the only timestamp that
makes sense is ktime_get_ns(). So in GPIO we just use that, all the
userspace I can think of certainly prefers monotonic time.
(If tglx does not agree with that I stand corrected to whatever
he says, I suppose.)

In general, CLOCK_MONOTONIC is what makes most sense.

The only other interesting clock which makes sense from an application
POV is CLOCK_TAI which is becoming more popular in terms of network wide
time coordination and TSN.

CLOCK_REALTIME is a pain to deal with due to leap seconds, daylight
savings etc.

Anyway in GPIO we could also make it configurable for users who
know what they are doing.

HW timestamps would be something more elaborate and
nice CLOCK_HW_SPECIFIC or so. Some of the IIO sensors also
have that, we just don't expose it as of now.

HW timestamps are just more accurate than the software timestamps which
we have now and from a portability and interface POV they should just be
converted converted / mapped to clock MONOTONIC or clock TAI. So your
existing interface (maybe extended to TAI in the future) is just
working, but more accurate.

Exposing the HW timestamp itself based on some random and potentially
unknown clock might still be useful for some specialized applications,
but that want's to be through a distinct interface so there is no chance
to confuse it with something generally useful.

Thanks,

        tglx