From: Daniel Vetter <daniel.vetter@ffwll.ch> To: DRI Development <dri-devel@lists.freedesktop.org> Cc: "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "Daniel Vetter" <daniel.vetter@ffwll.ch>, "Daniel Vetter" <daniel.vetter@intel.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Gustavo Padovan" <gustavo@padovan.org>, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, "Christian König" <christian.koenig@amd.com>, "Alex Deucher" <alexander.deucher@amd.com> Subject: [PATCH 04/17] dma-fence: Allow wait_any_timeout for all fences Date: Fri, 27 Apr 2018 08:17:11 +0200 [thread overview] Message-ID: <20180427061724.28497-5-daniel.vetter@ffwll.ch> (raw) In-Reply-To: <20180427061724.28497-1-daniel.vetter@ffwll.ch> When this was introduced in commit a519435a96597d8cd96123246fea4ae5a6c90b02 Author: Christian König <christian.koenig@amd.com> Date: Tue Oct 20 16:34:16 2015 +0200 dma-buf/fence: add fence_wait_any_timeout function v2 there was a restriction added that this only works if the dma-fence uses the dma_fence_default_wait hook. Which works for amdgpu, which is the only caller. Well, until you share some buffers with e.g. i915, then you get an -EINVAL. But there's really no reason for this, because all drivers must support callbacks. The special ->wait hook is only as an optimization; if the driver needs to create a worker thread for an active callback, then it can avoid to do that if it knows that there's a process context available already. So ->wait is just an optimization, just using the logic in dma_fence_default_wait() should work for all drivers. Let's remove this restriction. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> --- drivers/dma-buf/dma-fence.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 7b5b40d6b70e..59049375bd19 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -503,11 +503,6 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, uint32_t count, for (i = 0; i < count; ++i) { struct dma_fence *fence = fences[i]; - if (fence->ops->wait != dma_fence_default_wait) { - ret = -EINVAL; - goto fence_rm_cb; - } - cb[i].task = current; if (dma_fence_add_callback(fence, &cb[i].base, dma_fence_default_wait_cb)) { -- 2.17.0
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel.vetter@ffwll.ch> To: DRI Development <dri-devel@lists.freedesktop.org> Cc: "Intel Graphics Development" <intel-gfx@lists.freedesktop.org>, "Christian König" <christian.koenig@amd.com>, linaro-mm-sig@lists.linaro.org, "Daniel Vetter" <daniel.vetter@ffwll.ch>, "Alex Deucher" <alexander.deucher@amd.com>, "Daniel Vetter" <daniel.vetter@intel.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, linux-media@vger.kernel.org Subject: [PATCH 04/17] dma-fence: Allow wait_any_timeout for all fences Date: Fri, 27 Apr 2018 08:17:11 +0200 [thread overview] Message-ID: <20180427061724.28497-5-daniel.vetter@ffwll.ch> (raw) In-Reply-To: <20180427061724.28497-1-daniel.vetter@ffwll.ch> When this was introduced in commit a519435a96597d8cd96123246fea4ae5a6c90b02 Author: Christian König <christian.koenig@amd.com> Date: Tue Oct 20 16:34:16 2015 +0200 dma-buf/fence: add fence_wait_any_timeout function v2 there was a restriction added that this only works if the dma-fence uses the dma_fence_default_wait hook. Which works for amdgpu, which is the only caller. Well, until you share some buffers with e.g. i915, then you get an -EINVAL. But there's really no reason for this, because all drivers must support callbacks. The special ->wait hook is only as an optimization; if the driver needs to create a worker thread for an active callback, then it can avoid to do that if it knows that there's a process context available already. So ->wait is just an optimization, just using the logic in dma_fence_default_wait() should work for all drivers. Let's remove this restriction. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> --- drivers/dma-buf/dma-fence.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 7b5b40d6b70e..59049375bd19 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -503,11 +503,6 @@ dma_fence_wait_any_timeout(struct dma_fence **fences, uint32_t count, for (i = 0; i < count; ++i) { struct dma_fence *fence = fences[i]; - if (fence->ops->wait != dma_fence_default_wait) { - ret = -EINVAL; - goto fence_rm_cb; - } - cb[i].task = current; if (dma_fence_add_callback(fence, &cb[i].base, dma_fence_default_wait_cb)) { -- 2.17.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-04-27 6:17 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-27 6:17 [PATCH 00/17] dma-fence doc polish and small cleanup Daniel Vetter 2018-04-27 6:17 ` [PATCH 01/17] dma-fence: Some kerneldoc polish for dma-fence.h Daniel Vetter 2018-04-27 6:17 ` Daniel Vetter 2018-04-30 17:49 ` [Intel-gfx] " Eric Anholt 2018-04-30 17:49 ` Eric Anholt 2018-05-02 7:38 ` [Intel-gfx] " Daniel Vetter 2018-05-02 7:38 ` Daniel Vetter 2018-04-27 6:17 ` [PATCH 02/17] dma-fence: remove fill_driver_data callback Daniel Vetter 2018-04-30 17:49 ` Eric Anholt 2018-05-02 8:23 ` [PATCH] " Daniel Vetter 2018-05-02 16:57 ` Eric Anholt 2018-04-27 6:17 ` [PATCH 03/17] dma-fence: Make ->enable_signaling optional Daniel Vetter 2018-04-27 6:17 ` Daniel Vetter 2018-04-27 6:17 ` Daniel Vetter [this message] 2018-04-27 6:17 ` [PATCH 04/17] dma-fence: Allow wait_any_timeout for all fences Daniel Vetter 2018-04-29 7:11 ` Christian König 2018-04-29 7:11 ` Christian König 2018-04-30 15:35 ` Daniel Vetter 2018-04-30 15:35 ` Daniel Vetter 2018-04-27 6:17 ` [PATCH 05/17] dma-fence: Make ->wait callback optional Daniel Vetter 2018-04-27 6:17 ` Daniel Vetter 2018-04-27 6:17 ` [PATCH 06/17] drm/amdgpu: Remove unecessary dma_fence_ops Daniel Vetter 2018-04-29 7:12 ` Christian König 2018-04-27 6:17 ` [PATCH 07/17] drm: " Daniel Vetter 2018-04-30 17:51 ` Eric Anholt 2018-04-27 6:17 ` [PATCH 08/17] drm/etnaviv: " Daniel Vetter 2018-05-03 13:43 ` Lucas Stach 2018-04-27 6:17 ` [PATCH 09/17] drm/i915: " Daniel Vetter [not found] ` <20180427061724.28497-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org> 2018-04-27 6:17 ` [PATCH 10/17] drm/msm: " Daniel Vetter 2018-04-27 6:17 ` [PATCH 11/17] drm/nouveau: " Daniel Vetter 2018-04-27 6:17 ` [PATCH 12/17] drm/qxl: " Daniel Vetter 2018-04-30 17:53 ` Eric Anholt 2018-05-02 8:23 ` [PATCH] " Daniel Vetter 2018-05-02 8:23 ` Daniel Vetter 2018-04-27 6:17 ` [PATCH 13/17] drm/radeon: Remove custom dma_fence_ops->wait implementation Daniel Vetter 2018-04-29 7:08 ` Christian König 2018-04-30 15:38 ` Daniel Vetter [not found] ` <20180430153854.GR12521-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> 2018-04-30 18:26 ` Christian König [not found] ` <ba53bdbd-3311-5836-4529-5374ccf6584a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2018-04-30 19:35 ` Daniel Vetter 2018-04-27 6:17 ` [PATCH 14/17] drm/vc4: Remove unecessary dma_fence_ops Daniel Vetter 2018-04-30 17:50 ` Eric Anholt 2018-04-27 6:17 ` [PATCH 15/17] drm/vgem: " Daniel Vetter 2018-04-27 6:17 ` [PATCH 16/17] drm/virtio: " Daniel Vetter 2018-04-30 17:54 ` Eric Anholt 2018-04-27 6:17 ` [PATCH 17/17] dma-fence: Polish kernel-doc for dma-fence.c Daniel Vetter 2018-04-27 6:17 ` Daniel Vetter 2018-04-27 9:54 ` ✗ Fi.CI.CHECKPATCH: warning for dma-fence doc polish and small cleanup Patchwork 2018-04-27 10:06 ` ✗ Fi.CI.BAT: failure " Patchwork 2018-04-29 7:15 ` [PATCH 00/17] " Christian König 2018-05-02 12:19 ` ✗ Fi.CI.BAT: failure for dma-fence doc polish and small cleanup (rev3) Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180427061724.28497-5-daniel.vetter@ffwll.ch \ --to=daniel.vetter@ffwll.ch \ --cc=alexander.deucher@amd.com \ --cc=christian.koenig@amd.com \ --cc=daniel.vetter@intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=gustavo@padovan.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-media@vger.kernel.org \ --cc=sumit.semwal@linaro.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.