From: Inki Dae <inki.dae@samsung.com>
To: Gustavo Padovan <gustavo@padovan.org>, dri-devel@lists.freedesktop.org
Cc: "Daniel Stone" <daniels@collabora.com>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Arve Hjønnevåg" <arve@android.com>,
linux-kernel@vger.kernel.org,
"Riley Andrews" <riandrews@android.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
"John Harrison" <John.C.Harrison@Intel.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
Date: Thu, 24 Mar 2016 17:18:36 +0900 [thread overview]
Message-ID: <56F3A2DC.8080507@samsung.com> (raw)
In-Reply-To: <1458758847-21170-1-git-send-email-gustavo@padovan.org>
Hi,
2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Hi,
>
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a array with all
> fences that a atomic commit needs to wait on
As I mentioned already like below,
http://www.spinics.net/lists/dri-devel/msg103225.html
I don't see why Android specific thing is tried to propagate to Linux DRM. In Linux mainline, it has already implicit sync interfaces for DMA devices called dma fence which forces registering a fence obejct to DMABUF through a reservation obejct when a dmabuf object is created. However, Android sync driver creates a new file for a sync object and this would have different point of view.
Is there anyone who can explan why Android specific thing is tried to spread into Linux DRM? Was there any consensus to use Android sync driver - which uses explicit sync interfaces - as Linux standard?
Thanks,
Inki Dae
>
> /**
> * struct fence_collection - aggregate fences together
> * @num_fences: number of fence in the collection.
> * @user_data: user data.
> * @func: user callback to put user data.
> * @fences: array of @num_fences fences.
> */
> struct fence_collection {
> int num_fences;
> void *user_data;
> collection_put_func_t func;
> struct fence *fences[];
> };
>
>
> The fence_collection is allocated and filled by sync_file_fences_get() and
> atomic_commit helpers can use fence_collection_wait() to wait the fences to
> signal.
>
> These patches depends on the sync ABI rework:
>
> https://www.spinics.net/lists/dri-devel/msg102795.html
>
> and the patch to de-stage the sync framework:
>
> https://www.spinics.net/lists/dri-devel/msg102799.html
>
>
> I also hacked together some sync support into modetest for testing:
>
> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>
>
> Gustavo
>
>
> Gustavo Padovan (6):
> drm/fence: add FENCE_FD property to planes
> dma-buf/fence: add struct fence_collection
> dma-buf/sync_file: add sync_file_fences_get()
> dma-buf/fence: add fence_collection_put()
> dma-buf/fence: add fence_collection_wait()
> drm/fence: support fence_collection on atomic commit
>
> drivers/dma-buf/fence.c | 33 +++++++++++++++++++++++++++++++++
> drivers/dma-buf/sync_file.c | 36 ++++++++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_atomic.c | 13 +++++++++++++
> drivers/gpu/drm/drm_atomic_helper.c | 10 ++++++----
> drivers/gpu/drm/drm_crtc.c | 7 +++++++
> include/drm/drm_crtc.h | 5 ++++-
> include/linux/fence.h | 19 +++++++++++++++++++
> include/linux/sync_file.h | 8 ++++++++
> 8 files changed, 126 insertions(+), 5 deletions(-)
>
next prev parent reply other threads:[~2016-03-24 8:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 18:47 [RFC 0/6] drm/fences: add in-fences to DRM Gustavo Padovan
2016-03-23 18:47 ` [RFC 1/6] drm/fence: add FENCE_FD property to planes Gustavo Padovan
2016-04-05 12:36 ` Rob Clark
2016-04-05 12:57 ` Daniel Stone
2016-04-05 14:04 ` Rob Clark
2016-04-05 14:19 ` Daniel Stone
2016-04-05 15:23 ` Rob Clark
2016-03-23 18:47 ` [RFC 2/6] dma-buf/fence: add struct fence_collection Gustavo Padovan
2016-03-23 18:47 ` [RFC 3/6] dma-buf/sync_file: add sync_file_fences_get() Gustavo Padovan
2016-03-23 18:47 ` [RFC 4/6] dma-buf/fence: add fence_collection_put() Gustavo Padovan
2016-03-23 18:47 ` [RFC 5/6] dma-buf/fence: add fence_collection_wait() Gustavo Padovan
2016-03-23 18:47 ` [RFC 6/6] drm/fence: support fence_collection on atomic commit Gustavo Padovan
2016-03-24 7:20 ` [RFC 0/6] drm/fences: add in-fences to DRM Maarten Lankhorst
2016-03-24 14:31 ` Gustavo Padovan
2016-03-24 8:18 ` Inki Dae [this message]
2016-03-24 14:39 ` Gustavo Padovan
2016-03-24 23:03 ` Inki Dae
2016-03-24 15:40 ` Rob Clark
2016-03-24 23:49 ` Inki Dae
2016-03-25 11:58 ` Rob Clark
2016-03-25 12:10 ` Daniel Stone
2016-03-28 1:26 ` Inki Dae
2016-03-28 13:26 ` Daniel Stone
2016-03-29 2:18 ` Inki Dae
2016-03-29 13:23 ` Rob Clark
2016-03-31 7:45 ` Inki Dae
2016-03-31 9:35 ` Daniel Stone
2016-03-31 10:04 ` Daniel Vetter
2016-03-31 11:40 ` Inki Dae
2016-03-31 10:05 ` Inki Dae
2016-03-31 10:56 ` Daniel Stone
2016-03-31 11:26 ` Inki Dae
2016-03-31 11:41 ` Daniel Stone
2016-03-31 14:10 ` Rob Clark
2016-04-04 0:14 ` Inki Dae
2016-04-04 15:41 ` Rob Clark
2016-04-04 15:46 ` Rob Clark
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=56F3A2DC.8080507@samsung.com \
--to=inki.dae@samsung.com \
--cc=John.C.Harrison@Intel.com \
--cc=arve@android.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.padovan@collabora.co.uk \
--cc=gustavo@padovan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riandrews@android.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox