Hi Arnd, On 05/04/2015 12:14 PM, Arnd Bergmann wrote: > On Monday 04 May 2015 09:42:36 Hans Verkuil wrote: >> Ping! (Added Arnd to the CC list) > > Hi Hans, > > sorry I missed this the first time > >> On 04/27/2015 09:40 AM, Hans Verkuil wrote: >>> Added the y2038 mailinglist since I would like to get their input for >>> this API. >>> >>> Y2038 experts, can you take a look at my comment in the code below? >>> >>> Thanks! >> >> Arnd, I just saw your patch series adding struct __kernel_timespec to >> uapi/linux/time.h. I get the feeling that it might take a few kernel >> cycles before we have a timespec64 available in userspace. Based on that >> I think this CEC API should drop the timestamps for now and wait until >> timespec64 becomes available before adding it. >> >> The timestamps are a nice-to-have, but not critical. So adding it later >> shouldn't be a problem. What is your opinion? > > It will take a little while for the patches to make it in, I would guess > 4.3 at the earliest. Using your own struct works just as well and would > be less ambiguous. > > However, for timestamps, I would recommend not using timespec anyway. > Instead, just use a single 64-bit nanosecond value from ktime_get_ns() > (or ktime_get_boot_ns() if you need a time that keeps ticking across > suspend). This is more efficient to get and simpler to use as long > as you don't need to convert from nanosecond to timespec. Possibly stupid follow-up question: is ktime_get_ns() just a different representation as ktime_get_ts64()? Or is there some offset between the two? They seem to be identical based on a quick test, but I'd like to be certain that that's always the case. Users need to be able to relate this timestamp to a struct timespec as returned by V4L2 (and others). Thanks! Hans _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
