On Mon, 27 Sep 2021 07:36:05 -0700 Rob Clark robdclark@gmail.com wrote:
On Mon, Sep 27, 2021 at 1:42 AM Pekka Paalanen ppaalanen@gmail.com wrote:
On Fri, 3 Sep 2021 11:47:59 -0700 Rob Clark robdclark@gmail.com wrote:
From: Rob Clark robdclark@chromium.org
The initial purpose is for igt tests, but this would also be useful for compositors that wait until close to vblank deadline to make decisions about which frame to show.
Signed-off-by: Rob Clark robdclark@chromium.org
drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ include/uapi/linux/sync_file.h | 20 ++++++++++++++++++++ 2 files changed, 39 insertions(+)
...
diff --git a/include/uapi/linux/sync_file.h b/include/uapi/linux/sync_file.h index ee2dcfb3d660..f67d4ffe7566 100644 --- a/include/uapi/linux/sync_file.h +++ b/include/uapi/linux/sync_file.h @@ -67,6 +67,18 @@ struct sync_file_info { __u64 sync_fence_info; };
+/**
- struct sync_set_deadline - set a deadline on a fence
- @tv_sec: seconds elapsed since epoch
- @tv_nsec: nanoseconds elapsed since the time given by the tv_sec
- @pad: must be zero
Hi Rob,
I think you need to specify which clock this timestamp must be in.
Which epoch? Sounds a bit like CLOCK_REALTIME to me which would not make sense.
It should be monotonic.. same clock as is used for vblank timestamps, which I assume that would be the most straightforward thing for compositors to use
Yes, it would. Just need to document that. :-)
Thanks, pq