Message ID | 20230218211608.1630586-6-robdclark@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp553952wrn; Sat, 18 Feb 2023 13:17:13 -0800 (PST) X-Google-Smtp-Source: AK7set+Cz9KM0vxSqJnwlzI24Pby88y/fZcln61nYYTAQwq1n39dT6cVVl4/qo/m5u7eL/+vXnkO X-Received: by 2002:a62:79c7:0:b0:593:befd:848c with SMTP id u190-20020a6279c7000000b00593befd848cmr5312842pfc.16.1676755032822; Sat, 18 Feb 2023 13:17:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676755032; cv=none; d=google.com; s=arc-20160816; b=s/fCKCv2sJESMaFm7sYagjTUBixIua7iVtfWJHxtA2GfE80d01F2edgY0XoTrCQafw TZCnsrCF8L/EDhtc5Xzu9QEO4kfqn/FDhzqdCFVMv/yER4uMkvw/KdVEWWXGts2yufLn Z+JqyIzZGQqWGj5G76U8VIMuUAvdf0YQisO523E+jTtEkdKqn61NdAKkZWx+TYwHXm97 blShkEylllRbt1wLlifopm3uLmQwipIPHtJH1OpaFPzTgWwL4hIL3E0uIpCiTUfTk4ys bHVpyYNiv5JXCF0pVUyoYcelc7KEzKtrfvUOsRPGE3TS/UOwGXgKnFm2MEfjmk/Ed3CP JXSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=hI9qNsZmZouFqjT4Q7iKBhJP6Ch7PWCt+bcIXmzWxTA=; b=vZQDtKiv9WIwHLeYVpc69qU7BZU8FeMFcIhrrYHEaqLs9e998kGUCJgakEs+WKNtuE 1F525vRerzVQAaAbsIOK6YyLjoBQp3eixeJU7IkqaE95m6GlZrdtsqTrpd+4PasIsWpN bL6hMB161zuFhI8HxFIM7tzyUwklSk/3e+z/Z8Adc5ICL6nBOe9LvCFDys+jiRdq04X/ GyIIJyQh3zRY/fAo+Wv2E7mJLX2zMJxevtvXs1eL72dIK2p54AMmi9717zv3D7y7/zPs jqISFWaAeo63DOW+VYpp5XyNnBkXLlk2jwDi7T8xnB/LA694U+67SbyaPriFqXHTCoyp /Jvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="n8m0ik/8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q19-20020a056a00085300b005a8b856ad47si10559619pfk.7.2023.02.18.13.16.57; Sat, 18 Feb 2023 13:17:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="n8m0ik/8"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229817AbjBRVQT (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Sat, 18 Feb 2023 16:16:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42700 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229709AbjBRVQG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 18 Feb 2023 16:16:06 -0500 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 975D715CB2; Sat, 18 Feb 2023 13:15:55 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id n1so1451380plc.11; Sat, 18 Feb 2023 13:15:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hI9qNsZmZouFqjT4Q7iKBhJP6Ch7PWCt+bcIXmzWxTA=; b=n8m0ik/8SEVtlt4tLy+1xKXcajLNDaoTcnObCr8qoX1kosoaMIoPX31NBzsj7seG30 TaPhmBInQnPnfd0sbBYcu2Sjd2IA6FxDGaZmCXZoXtGjZW6hFd+e9Xciqw/mNaEUFrq1 hjgq42bMdkekPwZy8PzTS6/Xq4JcoVNW50YdZjMsh/w+8uyRIy6w/+AWEK3pPnMvauwT wNnyWecM/dDofyumtFxiSCy6DM51SXQm97P8nGKVnoB2XUwupExO/xZ5cnsTPvxIDZIP qmCKeD3CtfUoaR56Ve0CFhe2vvZV/cLqVUjPQ858IZhTD5rfzOW9nQ9q1HUMtmg9/Zl0 ZfYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=hI9qNsZmZouFqjT4Q7iKBhJP6Ch7PWCt+bcIXmzWxTA=; b=nWsKbyyIwWelqOmz6eJmexRq1iL+8On4/01gAZdYQq8td1ZoZB0FfzuekGR7JLMHVn e6iToVPLJpwEUvJrRNy01gsZQIJ9VNlz4YxHaEoyuCt0Jljc8W29JNQAsmM0l24/KnPU 2QPAyx0s6Jw6E3pEvbWbBjbN1x31tjGbhoF7FyD0R5rovH7VJXjM861CM+HLiQ6Um5yb wmGqWBSzhK1ZBGvvIuOKvSuQoBImayQNGvmAyc6YHn+UIXhAJ+PI+flcEmUabDp42tPr X6zXjMyTcW1T0+Mjb0vZ8frfNc2naeWdco8IHQsixs/ju5bRsypRxQ0v/ZFSrKoamLcl fJsQ== X-Gm-Message-State: AO0yUKVOi1Mcn11nXan6Toa06tEeupEueVOIYZvHBLHq+uU+4AR1TkF1 iOy4firbpNGxgtoEBXTgs8g= X-Received: by 2002:a17:902:f98d:b0:19a:a647:1881 with SMTP id ky13-20020a170902f98d00b0019aa6471881mr3492159plb.62.1676754955043; Sat, 18 Feb 2023 13:15:55 -0800 (PST) Received: from localhost (c-73-67-135-195.hsd1.or.comcast.net. [73.67.135.195]) by smtp.gmail.com with ESMTPSA id a14-20020a170902ecce00b0019934030f46sm5057523plh.132.2023.02.18.13.15.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Feb 2023 13:15:54 -0800 (PST) From: Rob Clark <robdclark@gmail.com> To: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>, =?utf-8?q?Christian_K=C3=B6nig?= <ckoenig.leichtzumerken@gmail.com>, =?utf-8?q?Michel_D=C3=A4nzer?= <michel@daenzer.net>, Tvrtko Ursulin <tvrtko.ursulin@intel.com>, Rodrigo Vivi <rodrigo.vivi@intel.com>, Alex Deucher <alexander.deucher@amd.com>, Pekka Paalanen <ppaalanen@gmail.com>, Simon Ser <contact@emersion.fr>, Rob Clark <robdclark@chromium.org>, Sumit Semwal <sumit.semwal@linaro.org>, Gustavo Padovan <gustavo@padovan.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, linux-media@vger.kernel.org (open list:SYNC FILE FRAMEWORK), linaro-mm-sig@lists.linaro.org (moderated list:DMA BUFFER SHARING FRAMEWORK), linux-kernel@vger.kernel.org (open list) Subject: [PATCH v4 05/14] dma-buf/sync_file: Add SET_DEADLINE ioctl Date: Sat, 18 Feb 2023 13:15:48 -0800 Message-Id: <20230218211608.1630586-6-robdclark@gmail.com> X-Mailer: git-send-email 2.39.1 In-Reply-To: <20230218211608.1630586-1-robdclark@gmail.com> References: <20230218211608.1630586-1-robdclark@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758205085366911967?= X-GMAIL-MSGID: =?utf-8?q?1758205085366911967?= |
Series |
dma-fence: Deadline awareness
|
|
Commit Message
Rob Clark
Feb. 18, 2023, 9:15 p.m. UTC
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. The igt tests can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v2: Clarify the timebase, add link to igt tests Signed-off-by: Rob Clark <robdclark@chromium.org> --- drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ include/uapi/linux/sync_file.h | 22 ++++++++++++++++++++++ 2 files changed, 41 insertions(+)
Comments
Am 18.02.23 um 22:15 schrieb Rob Clark: > 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. > > The igt tests can be found at: > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > v2: Clarify the timebase, add link to igt tests > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > include/uapi/linux/sync_file.h | 22 ++++++++++++++++++++++ > 2 files changed, 41 insertions(+) > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index af57799c86ce..fb6ca1032885 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -350,6 +350,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) > { > @@ -362,6 +378,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..c8666580816f 100644 > --- a/include/uapi/linux/sync_file.h > +++ b/include/uapi/linux/sync_file.h > @@ -67,6 +67,20 @@ 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 > + * > + * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank) > + */ > +struct sync_set_deadline { > + __s64 tv_sec; > + __s32 tv_nsec; > + __u32 pad; IIRC struct timespec defined this as time_t/long (which is horrible for an UAPI because of the sizeof(long) dependency), one possible alternative is to use 64bit nanoseconds from CLOCK_MONOTONIC (which is essentially ktime). Not 100% sure if there is any preferences documented, but I think the later might be better. Either way the patch is Acked-by: Christian König <christian.koenig@amd.com> for this patch. Regards, Christian. > +}; > + > #define SYNC_IOC_MAGIC '>' > > /** > @@ -95,4 +109,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 Sat, 18 Feb 2023 13:15:48 -0800 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. > > The igt tests can be found at: > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > v2: Clarify the timebase, add link to igt tests > > Signed-off-by: Rob Clark <robdclark@chromium.org> > --- > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > include/uapi/linux/sync_file.h | 22 ++++++++++++++++++++++ > 2 files changed, 41 insertions(+) > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index af57799c86ce..fb6ca1032885 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -350,6 +350,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) > { > @@ -362,6 +378,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..c8666580816f 100644 > --- a/include/uapi/linux/sync_file.h > +++ b/include/uapi/linux/sync_file.h > @@ -67,6 +67,20 @@ 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 Hi, should tv_sec,tv_nsec be validated like clock_settime() does? It requires: - tv_sec >= 0 - tv_nsec >= 0 - tv_nsec < 1e9 Thanks, pq > + * @pad: must be zero > + * > + * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank) > + */ > +struct sync_set_deadline { > + __s64 tv_sec; > + __s32 tv_nsec; > + __u32 pad; > +}; > + > #define SYNC_IOC_MAGIC '>' > > /** > @@ -95,4 +109,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, Feb 20, 2023 at 12:27 AM Christian König <christian.koenig@amd.com> wrote: > > Am 18.02.23 um 22:15 schrieb Rob Clark: > > 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. > > > > The igt tests can be found at: > > > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > > > v2: Clarify the timebase, add link to igt tests > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > --- > > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > > include/uapi/linux/sync_file.h | 22 ++++++++++++++++++++++ > > 2 files changed, 41 insertions(+) > > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > > index af57799c86ce..fb6ca1032885 100644 > > --- a/drivers/dma-buf/sync_file.c > > +++ b/drivers/dma-buf/sync_file.c > > @@ -350,6 +350,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) > > { > > @@ -362,6 +378,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..c8666580816f 100644 > > --- a/include/uapi/linux/sync_file.h > > +++ b/include/uapi/linux/sync_file.h > > @@ -67,6 +67,20 @@ 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 > > + * > > + * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank) > > + */ > > +struct sync_set_deadline { > > + __s64 tv_sec; > > + __s32 tv_nsec; > > + __u32 pad; > > IIRC struct timespec defined this as time_t/long (which is horrible for > an UAPI because of the sizeof(long) dependency), one possible > alternative is to use 64bit nanoseconds from CLOCK_MONOTONIC (which is > essentially ktime). > > Not 100% sure if there is any preferences documented, but I think the > later might be better. The original thought is that this maps directly to clock_gettime() without extra conversion needed, and is similar to other pre-ktime_t UAPI. But OTOH if userspace wants to add an offset, it is maybe better to convert completely to ns in userspace and use a u64 (as that is what ns_to_ktime() uses).. (and OFC whatever decision here also applies to the syncobj wait ioctls) I'm leaning towards u64 CLOCK_MONOTONIC ns if no one has a good argument against that. BR, -R > Either way the patch is Acked-by: Christian König > <christian.koenig@amd.com> for this patch. > > Regards, > Christian. > > > +}; > > + > > #define SYNC_IOC_MAGIC '>' > > > > /** > > @@ -95,4 +109,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, 20 Feb 2023 08:09:04 -0800 Rob Clark <robdclark@gmail.com> wrote: > On Mon, Feb 20, 2023 at 12:27 AM Christian König > <christian.koenig@amd.com> wrote: > > > > Am 18.02.23 um 22:15 schrieb Rob Clark: > > > 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. > > > > > > The igt tests can be found at: > > > > > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > > > > > v2: Clarify the timebase, add link to igt tests > > > > > > Signed-off-by: Rob Clark <robdclark@chromium.org> > > > --- > > > drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ > > > include/uapi/linux/sync_file.h | 22 ++++++++++++++++++++++ > > > 2 files changed, 41 insertions(+) > > > > > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > > > index af57799c86ce..fb6ca1032885 100644 > > > --- a/drivers/dma-buf/sync_file.c > > > +++ b/drivers/dma-buf/sync_file.c > > > @@ -350,6 +350,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) > > > { > > > @@ -362,6 +378,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..c8666580816f 100644 > > > --- a/include/uapi/linux/sync_file.h > > > +++ b/include/uapi/linux/sync_file.h > > > @@ -67,6 +67,20 @@ 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 > > > + * > > > + * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank) > > > + */ > > > +struct sync_set_deadline { > > > + __s64 tv_sec; > > > + __s32 tv_nsec; > > > + __u32 pad; > > > > IIRC struct timespec defined this as time_t/long (which is horrible for > > an UAPI because of the sizeof(long) dependency), one possible > > alternative is to use 64bit nanoseconds from CLOCK_MONOTONIC (which is > > essentially ktime). > > > > Not 100% sure if there is any preferences documented, but I think the > > later might be better. > > The original thought is that this maps directly to clock_gettime() > without extra conversion needed, and is similar to other pre-ktime_t > UAPI. But OTOH if userspace wants to add an offset, it is maybe > better to convert completely to ns in userspace and use a u64 (as that > is what ns_to_ktime() uses).. (and OFC whatever decision here also > applies to the syncobj wait ioctls) > > I'm leaning towards u64 CLOCK_MONOTONIC ns if no one has a good > argument against that. No, no good argument against that, it's just different from any other UAPI so far, but a new style has to start somewhere. It's good for 584 years after the epoch. Just make sure the documentation is explicit on how struct timespec is converted to and from u64 (signedness issues, overflow and whatnot). Thanks, pq > > BR, > -R > > > Either way the patch is Acked-by: Christian König > > <christian.koenig@amd.com> for this patch. > > > > Regards, > > Christian. > > > > > +}; > > > + > > > #define SYNC_IOC_MAGIC '>' > > > > > > /** > > > @@ -95,4 +109,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 20.02.23 um 17:09 schrieb Rob Clark: > On Mon, Feb 20, 2023 at 12:27 AM Christian König > <christian.koenig@amd.com> wrote: >> Am 18.02.23 um 22:15 schrieb Rob Clark: >>> 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. >>> >>> The igt tests can be found at: >>> >>> https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline >>> >>> v2: Clarify the timebase, add link to igt tests >>> >>> Signed-off-by: Rob Clark <robdclark@chromium.org> >>> --- >>> drivers/dma-buf/sync_file.c | 19 +++++++++++++++++++ >>> include/uapi/linux/sync_file.h | 22 ++++++++++++++++++++++ >>> 2 files changed, 41 insertions(+) >>> >>> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c >>> index af57799c86ce..fb6ca1032885 100644 >>> --- a/drivers/dma-buf/sync_file.c >>> +++ b/drivers/dma-buf/sync_file.c >>> @@ -350,6 +350,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) >>> { >>> @@ -362,6 +378,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..c8666580816f 100644 >>> --- a/include/uapi/linux/sync_file.h >>> +++ b/include/uapi/linux/sync_file.h >>> @@ -67,6 +67,20 @@ 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 >>> + * >>> + * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank) >>> + */ >>> +struct sync_set_deadline { >>> + __s64 tv_sec; >>> + __s32 tv_nsec; >>> + __u32 pad; >> IIRC struct timespec defined this as time_t/long (which is horrible for >> an UAPI because of the sizeof(long) dependency), one possible >> alternative is to use 64bit nanoseconds from CLOCK_MONOTONIC (which is >> essentially ktime). >> >> Not 100% sure if there is any preferences documented, but I think the >> later might be better. > The original thought is that this maps directly to clock_gettime() > without extra conversion needed, and is similar to other pre-ktime_t > UAPI. But OTOH if userspace wants to add an offset, it is maybe > better to convert completely to ns in userspace and use a u64 (as that > is what ns_to_ktime() uses).. (and OFC whatever decision here also > applies to the syncobj wait ioctls) > > I'm leaning towards u64 CLOCK_MONOTONIC ns if no one has a good > argument against that. +1 for that. Regards, Christian. > > BR, > -R > >> Either way the patch is Acked-by: Christian König >> <christian.koenig@amd.com> for this patch. >> >> Regards, >> Christian. >> >>> +}; >>> + >>> #define SYNC_IOC_MAGIC '>' >>> >>> /** >>> @@ -95,4 +109,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 */
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index af57799c86ce..fb6ca1032885 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -350,6 +350,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) { @@ -362,6 +378,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..c8666580816f 100644 --- a/include/uapi/linux/sync_file.h +++ b/include/uapi/linux/sync_file.h @@ -67,6 +67,20 @@ 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 + * + * The timebase for the deadline is CLOCK_MONOTONIC (same as vblank) + */ +struct sync_set_deadline { + __s64 tv_sec; + __s32 tv_nsec; + __u32 pad; +}; + #define SYNC_IOC_MAGIC '>' /** @@ -95,4 +109,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 */