| Message ID | 20210903184806.1680887-9-robdclark@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | dma-fence: Deadline awareness | expand |
On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark 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> > > Needs userspace and I think ideally also some igts to make sure it works > and doesn't go boom. See cover-letter.. there are igt tests, although currently that is the only user. I'd be ok to otherwise initially restrict this and the sw_sync UABI (CAP_SYS_ADMIN? Or??) until there is a non-igt user, but they are both needed by the igt tests BR, -R > -Daniel > > > --- > > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > > include/uapi/linux/sync_file.h | 20 ++++++++++++++++++++ > > 2 files changed, 39 insertions(+) > > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > > index 394e6e1e9686..f295772d5169 100644 > > --- a/drivers/dma-buf/sync_file.c > > +++ b/drivers/dma-buf/sync_file.c > > @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, > > return ret; > > } > > > > +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file, > > + unsigned long arg) > > +{ > > + struct sync_set_deadline ts; > > + > > + if (copy_from_user(&ts, (void __user *)arg, sizeof(ts))) > > + return -EFAULT; > > + > > + if (ts.pad) > > + return -EINVAL; > > + > > + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec, ts.tv_nsec)); > > + > > + return 0; > > +} > > + > > static long sync_file_ioctl(struct file *file, unsigned int cmd, > > unsigned long arg) > > { > > @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd, > > case SYNC_IOC_FILE_INFO: > > return sync_file_ioctl_fence_info(sync_file, arg); > > > > + case SYNC_IOC_SET_DEADLINE: > > + return sync_file_ioctl_set_deadline(sync_file, arg); > > + > > default: > > return -ENOTTY; > > } > > 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 > > + */ > > +struct sync_set_deadline { > > + __s64 tv_sec; > > + __s32 tv_nsec; > > + __u32 pad; > > +}; > > + > > #define SYNC_IOC_MAGIC '>' > > > > /** > > @@ -95,4 +107,12 @@ struct sync_file_info { > > */ > > #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) > > > > + > > +/** > > + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence > > + * > > + * Allows userspace to set a deadline on a fence, see dma_fence_set_deadline() > > + */ > > +#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline) > > + > > #endif /* _UAPI_LINUX_SYNC_H */ > > -- > > 2.31.1 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
On Wed, Sep 08, 2021 at 11:23:42AM -0700, Rob Clark wrote: > On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark 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> > > > > Needs userspace and I think ideally also some igts to make sure it works > > and doesn't go boom. > > See cover-letter.. there are igt tests, although currently that is the > only user. Ah sorry missed that. It would be good to record that in the commit too that adds the uapi. git blame doesn't find cover letters at all, unlike on gitlab where you get the MR request with everything. Ok there is the Link: thing, but since that only points at the last version all the interesting discussion is still usually lost, so I tend to not bother looking there. > I'd be ok to otherwise initially restrict this and the sw_sync UABI > (CAP_SYS_ADMIN? Or??) until there is a non-igt user, but they are > both needed by the igt tests Hm really awkward, uapi for igts in cross vendor stuff like this isn't great. I think hiding it in vgem is semi-ok (we have fences there already). But it's all a bit silly ... For the tests, should we instead have a selftest/Kunit thing to exercise this stuff? igt probably not quite the right thing. Or combine with a page flip if you want to test msm. -Daniel > > BR, > -R > > > -Daniel > > > > > --- > > > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > > > include/uapi/linux/sync_file.h | 20 ++++++++++++++++++++ > > > 2 files changed, 39 insertions(+) > > > > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > > > index 394e6e1e9686..f295772d5169 100644 > > > --- a/drivers/dma-buf/sync_file.c > > > +++ b/drivers/dma-buf/sync_file.c > > > @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, > > > return ret; > > > } > > > > > > +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file, > > > + unsigned long arg) > > > +{ > > > + struct sync_set_deadline ts; > > > + > > > + if (copy_from_user(&ts, (void __user *)arg, sizeof(ts))) > > > + return -EFAULT; > > > + > > > + if (ts.pad) > > > + return -EINVAL; > > > + > > > + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec, ts.tv_nsec)); > > > + > > > + return 0; > > > +} > > > + > > > static long sync_file_ioctl(struct file *file, unsigned int cmd, > > > unsigned long arg) > > > { > > > @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd, > > > case SYNC_IOC_FILE_INFO: > > > return sync_file_ioctl_fence_info(sync_file, arg); > > > > > > + case SYNC_IOC_SET_DEADLINE: > > > + return sync_file_ioctl_set_deadline(sync_file, arg); > > > + > > > default: > > > return -ENOTTY; > > > } > > > 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 > > > + */ > > > +struct sync_set_deadline { > > > + __s64 tv_sec; > > > + __s32 tv_nsec; > > > + __u32 pad; > > > +}; > > > + > > > #define SYNC_IOC_MAGIC '>' > > > > > > /** > > > @@ -95,4 +107,12 @@ struct sync_file_info { > > > */ > > > #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) > > > > > > + > > > +/** > > > + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence > > > + * > > > + * Allows userspace to set a deadline on a fence, see dma_fence_set_deadline() > > > + */ > > > +#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline) > > > + > > > #endif /* _UAPI_LINUX_SYNC_H */ > > > -- > > > 2.31.1 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
On Wed, Sep 8, 2021 at 9:36 PM Rob Clark <robdclark@gmail.com> wrote: > On Wed, Sep 8, 2021 at 11:49 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Sep 08, 2021 at 11:23:42AM -0700, Rob Clark wrote: > > > On Wed, Sep 8, 2021 at 10:50 AM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > > > > > On Fri, Sep 03, 2021 at 11:47:59AM -0700, Rob Clark 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> > > > > > > > > Needs userspace and I think ideally also some igts to make sure it works > > > > and doesn't go boom. > > > > > > See cover-letter.. there are igt tests, although currently that is the > > > only user. > > > > Ah sorry missed that. It would be good to record that in the commit too > > that adds the uapi. git blame doesn't find cover letters at all, unlike on > > gitlab where you get the MR request with everything. > > > > Ok there is the Link: thing, but since that only points at the last > > version all the interesting discussion is still usually lost, so I tend to > > not bother looking there. > > > > > I'd be ok to otherwise initially restrict this and the sw_sync UABI > > > (CAP_SYS_ADMIN? Or??) until there is a non-igt user, but they are > > > both needed by the igt tests > > > > Hm really awkward, uapi for igts in cross vendor stuff like this isn't > > great. I think hiding it in vgem is semi-ok (we have fences there > > already). But it's all a bit silly ... > > > > For the tests, should we instead have a selftest/Kunit thing to exercise > > this stuff? igt probably not quite the right thing. Or combine with a page > > flip if you want to test msm. > > Hmm, IIRC we have used CONFIG_BROKEN or something along those lines > for UABI in other places where we weren't willing to commit to yet? > > I suppose if we had to I could make this a sw_sync ioctl instead. But > OTOH there are kind of a limited # of ways this ioctl could look. And > we already know that at least some wayland compositors are going to > want this. Hm I was trying to think up a few ways this could work, but didn't come up with anything reasonable. Forcing the compositor to boost the entire chain (for gl composited primary plane fallback) is something the kernel can easily do too. Also only makes sense for priority boost, not so much for clock boosting, since clock boosting only really needs the final element to be boosted. > I guess I can look at non-igt options. But the igt test is already a > pretty convenient way to contrive situations (like loops, which is a > thing I need to add) Yeah it's definitely very useful for testing ... One option could be a hacky debugfs interface, where you write a fd number and deadline and the debugfs read function does the deadline setting. Horribly, but since it's debugfs no one ever cares. That's at least where we're hiding all the i915 hacks that igts need. -Daniel > BR, > -R > > > > -Daniel > > > > > > > > BR, > > > -R > > > > > > > -Daniel > > > > > > > > > --- > > > > > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > > > > > include/uapi/linux/sync_file.h | 20 ++++++++++++++++++++ > > > > > 2 files changed, 39 insertions(+) > > > > > > > > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > > > > > index 394e6e1e9686..f295772d5169 100644 > > > > > --- a/drivers/dma-buf/sync_file.c > > > > > +++ b/drivers/dma-buf/sync_file.c > > > > > @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, > > > > > return ret; > > > > > } > > > > > > > > > > +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file, > > > > > + unsigned long arg) > > > > > +{ > > > > > + struct sync_set_deadline ts; > > > > > + > > > > > + if (copy_from_user(&ts, (void __user *)arg, sizeof(ts))) > > > > > + return -EFAULT; > > > > > + > > > > > + if (ts.pad) > > > > > + return -EINVAL; > > > > > + > > > > > + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec, ts.tv_nsec)); > > > > > + > > > > > + return 0; > > > > > +} > > > > > + > > > > > static long sync_file_ioctl(struct file *file, unsigned int cmd, > > > > > unsigned long arg) > > > > > { > > > > > @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd, > > > > > case SYNC_IOC_FILE_INFO: > > > > > return sync_file_ioctl_fence_info(sync_file, arg); > > > > > > > > > > + case SYNC_IOC_SET_DEADLINE: > > > > > + return sync_file_ioctl_set_deadline(sync_file, arg); > > > > > + > > > > > default: > > > > > return -ENOTTY; > > > > > } > > > > > 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 > > > > > + */ > > > > > +struct sync_set_deadline { > > > > > + __s64 tv_sec; > > > > > + __s32 tv_nsec; > > > > > + __u32 pad; > > > > > +}; > > > > > + > > > > > #define SYNC_IOC_MAGIC '>' > > > > > > > > > > /** > > > > > @@ -95,4 +107,12 @@ struct sync_file_info { > > > > > */ > > > > > #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) > > > > > > > > > > + > > > > > +/** > > > > > + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence > > > > > + * > > > > > + * Allows userspace to set a deadline on a fence, see dma_fence_set_deadline() > > > > > + */ > > > > > +#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline) > > > > > + > > > > > #endif /* _UAPI_LINUX_SYNC_H */ > > > > > -- > > > > > 2.31.1 > > > > > > > > > > > > > -- > > > > Daniel Vetter > > > > Software Engineer, Intel Corporation > > > > http://blog.ffwll.ch > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch
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/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index 394e6e1e9686..f295772d5169 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, > return ret; > } > > +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file, > + unsigned long arg) > +{ > + struct sync_set_deadline ts; > + > + if (copy_from_user(&ts, (void __user *)arg, sizeof(ts))) > + return -EFAULT; > + > + if (ts.pad) > + return -EINVAL; > + > + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec, ts.tv_nsec)); > + > + return 0; > +} > + > static long sync_file_ioctl(struct file *file, unsigned int cmd, > unsigned long arg) > { > @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd, > case SYNC_IOC_FILE_INFO: > return sync_file_ioctl_fence_info(sync_file, arg); > > + case SYNC_IOC_SET_DEADLINE: > + return sync_file_ioctl_set_deadline(sync_file, arg); > + > default: > return -ENOTTY; > } > 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. Also I cannot guess how a compositor should be using this, so explaining the expected usage would be really good, with reasons for why should userspace bother. Thanks, pq > + */ > +struct sync_set_deadline { > + __s64 tv_sec; > + __s32 tv_nsec; > + __u32 pad; > +}; > + > #define SYNC_IOC_MAGIC '>' > > /** > @@ -95,4 +107,12 @@ struct sync_file_info { > */ > #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) > > + > +/** > + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence > + * > + * Allows userspace to set a deadline on a fence, see dma_fence_set_deadline() > + */ > +#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline) > + > #endif /* _UAPI_LINUX_SYNC_H */
Am 27.09.21 um 10:42 schrieb Pekka Paalanen: > 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/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c >> index 394e6e1e9686..f295772d5169 100644 >> --- a/drivers/dma-buf/sync_file.c >> +++ b/drivers/dma-buf/sync_file.c >> @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, >> return ret; >> } >> >> +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file, >> + unsigned long arg) >> +{ >> + struct sync_set_deadline ts; >> + >> + if (copy_from_user(&ts, (void __user *)arg, sizeof(ts))) >> + return -EFAULT; >> + >> + if (ts.pad) >> + return -EINVAL; >> + >> + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec, ts.tv_nsec)); >> + >> + return 0; >> +} >> + >> static long sync_file_ioctl(struct file *file, unsigned int cmd, >> unsigned long arg) >> { >> @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd, >> case SYNC_IOC_FILE_INFO: >> return sync_file_ioctl_fence_info(sync_file, arg); >> >> + case SYNC_IOC_SET_DEADLINE: >> + return sync_file_ioctl_set_deadline(sync_file, arg); >> + >> default: >> return -ENOTTY; >> } >> 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. Most likely CLOCK_MONOTONIC I think since that's what ktime is based on as well IIRC. My recollection might be wrong but I think Daniel documented somewhere that an absolut 64bit nanosecond value should be used for timeouts in IOCTLs which is sufficient for ~500 years uptime. So the separation between seconds and nanoseconds might be redundant. Regards, Christian. > > Also I cannot guess how a compositor should be using this, so > explaining the expected usage would be really good, with reasons for > why should userspace bother. > > > Thanks, > pq > >> + */ >> +struct sync_set_deadline { >> + __s64 tv_sec; >> + __s32 tv_nsec; >> + __u32 pad; >> +}; >> + >> #define SYNC_IOC_MAGIC '>' >> >> /** >> @@ -95,4 +107,12 @@ struct sync_file_info { >> */ >> #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) >> >> + >> +/** >> + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence >> + * >> + * Allows userspace to set a deadline on a fence, see dma_fence_set_deadline() >> + */ >> +#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline) >> + >> #endif /* _UAPI_LINUX_SYNC_H */
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
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index 394e6e1e9686..f295772d5169 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -459,6 +459,22 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, return ret; } +static int sync_file_ioctl_set_deadline(struct sync_file *sync_file, + unsigned long arg) +{ + struct sync_set_deadline ts; + + if (copy_from_user(&ts, (void __user *)arg, sizeof(ts))) + return -EFAULT; + + if (ts.pad) + return -EINVAL; + + dma_fence_set_deadline(sync_file->fence, ktime_set(ts.tv_sec, ts.tv_nsec)); + + return 0; +} + static long sync_file_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { @@ -471,6 +487,9 @@ static long sync_file_ioctl(struct file *file, unsigned int cmd, case SYNC_IOC_FILE_INFO: return sync_file_ioctl_fence_info(sync_file, arg); + case SYNC_IOC_SET_DEADLINE: + return sync_file_ioctl_set_deadline(sync_file, arg); + default: return -ENOTTY; } 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 + */ +struct sync_set_deadline { + __s64 tv_sec; + __s32 tv_nsec; + __u32 pad; +}; + #define SYNC_IOC_MAGIC '>' /** @@ -95,4 +107,12 @@ struct sync_file_info { */ #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) + +/** + * DOC: SYNC_IOC_SET_DEADLINE - set a deadline on a fence + * + * Allows userspace to set a deadline on a fence, see dma_fence_set_deadline() + */ +#define SYNC_IOC_SET_DEADLINE _IOW(SYNC_IOC_MAGIC, 5, struct sync_set_deadline) + #endif /* _UAPI_LINUX_SYNC_H */