From: "Christian König" <deathsimple@vodafone.de> To: Sumit Semwal <sumit.semwal@linaro.org>, Gustavo Padovan <gustavo@padovan.org>, DRI mailing list <dri-devel@lists.freedesktop.org>, LKML <linux-kernel@vger.kernel.org>, Chris Wilson <chris@chris-wilson.co.uk> Subject: Re: [PATCH 02/11] dma-buf/fence: add fence_array fences v6 Date: Thu, 2 Jun 2016 09:20:15 +0200 [thread overview] Message-ID: <574FDE2F.1060401@vodafone.de> (raw) In-Reply-To: <20160601224450.GD7231@phenom.ffwll.local> Am 02.06.2016 um 00:44 schrieb Daniel Vetter: > On Wed, Jun 01, 2016 at 09:54:04PM +0530, Sumit Semwal wrote: >> Hi Christian, Gustavo, >> >> Thanks for these patches. >> >> On 1 June 2016 at 20:55, Gustavo Padovan <gustavo@padovan.org> wrote: >>> 2016-06-01 Christian König <deathsimple@vodafone.de>: >>> >>>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >>>> >>>> struct fence_collection inherits from struct fence and carries a >>>> collection of fences that needs to be waited together. >>>> >>>> It is useful to translate a sync_file to a fence to remove the complexity >>>> of dealing with sync_files on DRM drivers. So even if there are many >>>> fences in the sync_file that needs to waited for a commit to happen, >>>> they all get added to the fence_collection and passed for DRM use as >>>> a standard struct fence. >>>> >>>> That means that no changes needed to any driver besides supporting fences. >>>> >>>> fence_collection's fence doesn't belong to any timeline context, so >>>> fence_is_later() and fence_later() are not meant to be called with >>>> fence_collections fences. >>>> >>>> v2: Comments by Daniel Vetter: >>>> - merge fence_collection_init() and fence_collection_add() >>>> - only add callbacks at ->enable_signalling() >>>> - remove fence_collection_put() >>>> - check for type on to_fence_collection() >>>> - adjust fence_is_later() and fence_later() to WARN_ON() if they >>>> are used with collection fences. >>>> >>>> v3: - Initialize fence_cb.node at fence init. >>>> >>>> Comments by Chris Wilson: >>>> - return "unbound" on fence_collection_get_timeline_name() >>>> - don't stop adding callbacks if one fails >>>> - remove redundant !! on fence_collection_enable_signaling() >>>> - remove redundant () on fence_collection_signaled >>>> - use fence_default_wait() instead >>>> >>>> v4 (chk): Rework, simplification and cleanup: >>>> - Drop FENCE_NO_CONTEXT handling, always allocate a context. >>>> - Rename to fence_array. >>>> - Return fixed driver name. >>>> - Register only one callback at a time. >>>> - Document that create function takes ownership of array. >>>> >>>> v5 (chk): More work and fixes: >>>> - Avoid deadlocks by adding all callbacks at once again. >>>> - Stop trying to remove the callbacks. >>>> - Provide context and sequence number for the array fence. >>>> >>>> v6 (chk): Fixes found during testing >>>> - Fix stupid typo in _enable_signaling(). >>>> >>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >>>> Signed-off-by: Christian König <christian.koenig@amd.com> >>>> --- >>>> drivers/dma-buf/Makefile | 2 +- >>>> drivers/dma-buf/fence-array.c | 127 ++++++++++++++++++++++++++++++++++++++++++ >>>> include/linux/fence-array.h | 72 ++++++++++++++++++++++++ >>>> 3 files changed, 200 insertions(+), 1 deletion(-) >>>> create mode 100644 drivers/dma-buf/fence-array.c >>>> create mode 100644 include/linux/fence-array.h >>> This is working fine to me. Once the commit message is fixed: >>> >>> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >>> >>> You need to Cc Sumit here to decide who is picking these patches. >>> It would be better to get them through the drm trees so we would need >>> his Ack at least. >>> >> +1 on the commit message consistency change; post that, please feel >> free to add my >> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> >> >> for the 3 dma-buf/fences patches and request to take them via DRM tree >> as rightly suggested by Gustavo. > Commit message improved and all 3 queued up for drm-misc. I haven't pushed > out the new branch yet though, since I'm waiting for Dave to open drm-next > and pull in a few other bits first so that I can rebase. Thanks and sorry for missing the commit message. I was a bit to concentrated on fixing the code. Leave me a note when the branch is public available, cause I then want to rebase the amdgpu changes on top and send a pull request to Alex. Christian. > > Thanks, Daniel
WARNING: multiple messages have this Message-ID (diff)
From: "Christian König" <deathsimple@vodafone.de> To: Sumit Semwal <sumit.semwal@linaro.org>, Gustavo Padovan <gustavo@padovan.org>, DRI mailing list <dri-devel@lists.freedesktop.org>, LKML <linux-kernel@vger.kernel.org>, Chris Wilson <chris@chris-wilson.co.uk> Subject: Re: [PATCH 02/11] dma-buf/fence: add fence_array fences v6 Date: Thu, 2 Jun 2016 09:20:15 +0200 [thread overview] Message-ID: <574FDE2F.1060401@vodafone.de> (raw) In-Reply-To: <20160601224450.GD7231@phenom.ffwll.local> Am 02.06.2016 um 00:44 schrieb Daniel Vetter: > On Wed, Jun 01, 2016 at 09:54:04PM +0530, Sumit Semwal wrote: >> Hi Christian, Gustavo, >> >> Thanks for these patches. >> >> On 1 June 2016 at 20:55, Gustavo Padovan <gustavo@padovan.org> wrote: >>> 2016-06-01 Christian König <deathsimple@vodafone.de>: >>> >>>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >>>> >>>> struct fence_collection inherits from struct fence and carries a >>>> collection of fences that needs to be waited together. >>>> >>>> It is useful to translate a sync_file to a fence to remove the complexity >>>> of dealing with sync_files on DRM drivers. So even if there are many >>>> fences in the sync_file that needs to waited for a commit to happen, >>>> they all get added to the fence_collection and passed for DRM use as >>>> a standard struct fence. >>>> >>>> That means that no changes needed to any driver besides supporting fences. >>>> >>>> fence_collection's fence doesn't belong to any timeline context, so >>>> fence_is_later() and fence_later() are not meant to be called with >>>> fence_collections fences. >>>> >>>> v2: Comments by Daniel Vetter: >>>> - merge fence_collection_init() and fence_collection_add() >>>> - only add callbacks at ->enable_signalling() >>>> - remove fence_collection_put() >>>> - check for type on to_fence_collection() >>>> - adjust fence_is_later() and fence_later() to WARN_ON() if they >>>> are used with collection fences. >>>> >>>> v3: - Initialize fence_cb.node at fence init. >>>> >>>> Comments by Chris Wilson: >>>> - return "unbound" on fence_collection_get_timeline_name() >>>> - don't stop adding callbacks if one fails >>>> - remove redundant !! on fence_collection_enable_signaling() >>>> - remove redundant () on fence_collection_signaled >>>> - use fence_default_wait() instead >>>> >>>> v4 (chk): Rework, simplification and cleanup: >>>> - Drop FENCE_NO_CONTEXT handling, always allocate a context. >>>> - Rename to fence_array. >>>> - Return fixed driver name. >>>> - Register only one callback at a time. >>>> - Document that create function takes ownership of array. >>>> >>>> v5 (chk): More work and fixes: >>>> - Avoid deadlocks by adding all callbacks at once again. >>>> - Stop trying to remove the callbacks. >>>> - Provide context and sequence number for the array fence. >>>> >>>> v6 (chk): Fixes found during testing >>>> - Fix stupid typo in _enable_signaling(). >>>> >>>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >>>> Signed-off-by: Christian König <christian.koenig@amd.com> >>>> --- >>>> drivers/dma-buf/Makefile | 2 +- >>>> drivers/dma-buf/fence-array.c | 127 ++++++++++++++++++++++++++++++++++++++++++ >>>> include/linux/fence-array.h | 72 ++++++++++++++++++++++++ >>>> 3 files changed, 200 insertions(+), 1 deletion(-) >>>> create mode 100644 drivers/dma-buf/fence-array.c >>>> create mode 100644 include/linux/fence-array.h >>> This is working fine to me. Once the commit message is fixed: >>> >>> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> >>> >>> You need to Cc Sumit here to decide who is picking these patches. >>> It would be better to get them through the drm trees so we would need >>> his Ack at least. >>> >> +1 on the commit message consistency change; post that, please feel >> free to add my >> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> >> >> for the 3 dma-buf/fences patches and request to take them via DRM tree >> as rightly suggested by Gustavo. > Commit message improved and all 3 queued up for drm-misc. I haven't pushed > out the new branch yet though, since I'm waiting for Dave to open drm-next > and pull in a few other bits first so that I can rebase. Thanks and sorry for missing the commit message. I was a bit to concentrated on fixing the code. Leave me a note when the branch is public available, cause I then want to rebase the amdgpu changes on top and send a pull request to Alex. Christian. > > Thanks, Daniel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2016-06-02 7:20 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-01 13:10 Fence array patchset Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 01/11] dma-buf/fence: make fence context 64 bit v2 Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 15:23 ` Gustavo Padovan 2016-06-01 15:23 ` Gustavo Padovan 2016-06-01 13:10 ` [PATCH 02/11] dma-buf/fence: add fence_array fences v6 Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 14:01 ` Gustavo Padovan 2016-06-01 14:01 ` Gustavo Padovan 2016-06-01 15:25 ` Gustavo Padovan 2016-06-01 15:25 ` Gustavo Padovan 2016-06-01 16:24 ` Sumit Semwal 2016-06-01 16:24 ` Sumit Semwal 2016-06-01 22:44 ` Daniel Vetter 2016-06-01 22:44 ` Daniel Vetter 2016-06-02 7:20 ` Christian König [this message] 2016-06-02 7:20 ` Christian König 2016-06-01 13:10 ` [PATCH 03/11] dma-buf/fence: add signal_on_any to the fence array v2 Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 15:25 ` Gustavo Padovan 2016-06-01 15:25 ` Gustavo Padovan 2016-06-01 13:10 ` [PATCH 04/11] drm/amdgpu: document amdgpu_sync_get_fence Christian König 2016-06-01 13:10 ` [PATCH 05/11] drm/amdgpu: generalize the scheduler fence Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 06/11] drm/amdgpu: remove amdgpu_sync_wait Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 07/11] drm/amdgpu: add optional ring to amdgpu_sync_is_idle Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 08/11] drm/amdgpu: prefer VMIDs idle on the current ring Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 09/11] drm/amdgpu: reuse VMIDs assigned to a VM only if there is also a free one Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 10/11] drm/amdgpu: use a fence array for VMID management Christian König 2016-06-01 13:10 ` Christian König 2016-06-01 13:10 ` [PATCH 11/11] drm/amdgpu: remove now unnecessary checks Christian König 2016-06-01 13:10 ` Christian König 2016-06-06 21:14 ` Alex Deucher 2016-06-06 21:14 ` Alex Deucher 2016-06-01 13:42 ` Fence array patchset Alex Deucher 2016-06-01 13:42 ` Alex Deucher
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=574FDE2F.1060401@vodafone.de \ --to=deathsimple@vodafone.de \ --cc=chris@chris-wilson.co.uk \ --cc=dri-devel@lists.freedesktop.org \ --cc=gustavo@padovan.org \ --cc=linux-kernel@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.