Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756610AbcCXISz (ORCPT ); Thu, 24 Mar 2016 04:18:55 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:37174 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932319AbcCXISi convert rfc822-to-8bit (ORCPT ); Thu, 24 Mar 2016 04:18:38 -0400 X-AuditID: cbfee690-f79646d000001316-ac-56f3a2dc895c MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8BIT Message-id: <56F3A2DC.8080507@samsung.com> Date: Thu, 24 Mar 2016 17:18:36 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Gustavo Padovan , dri-devel@lists.freedesktop.org Cc: Daniel Stone , Daniel Vetter , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , linux-kernel@vger.kernel.org, Riley Andrews , Gustavo Padovan , John Harrison Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> In-reply-to: <1458758847-21170-1-git-send-email-gustavo@padovan.org> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsWyRsSkWPfOos9hBnevy1m8/3ufzWLhw7vM Fpv6t7JbXPn6ns3i0+pWdoudD3axW0x6+oDN4vKuOWwWrzf9ZXTg9Ni2exurx9/n11k8dtxd wuix99sCFo/Fe14yedzvPs7ksXPSXiaPz5vkAjiiuGxSUnMyy1KL9O0SuDIOrysraJSo6O84 zdLA2CzcxcjJISFgInF+4RpWCFtM4sK99WxdjFwcQgIrGCWa1+xhgSnqONwPViQksJRRomGb AIjNKyAo8WPyPaAaDg5mAXWJKVNyQcLMAiISf3buZoKwtSWWLXzNDDHzAaPE/af32CF6tSSm nWgHm88ioCpx8OUksAY2IHviivtsIDNFBSIkuk9UgoRFBLwkns1bygIyh1lgG5NE97I+sHuE Bcwleh92Qt3mLHH5322wmZwCLhJL72yHeuwnu0RXszrELgGJb5MPgd0sISArsekAM0SJpMTB FTdYJjCKz0Ly2SyEz2Yh+WwWks8WMLKsYhRNLUguKE5KLzLRK07MLS7NS9dLzs/dxAiM6NP/ nk3YwXjvgPUhRgEORiUe3htcn8OEWBPLiitzDzGaAh00kVlKNDkfmDbySuINjc2MLExNTI2N zC3NlMR5X0v9DBYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaF0n0zIp+MXqXfFBdTnsDm+b ljJffq+5PXDevJ1f3jcdOst2YGKA2s0NkuYWX5aIX3F7tfyO/ZVwYWONXdJnhd8dcJBZ/lv8 w9dLZdq394vEn4qpeS9WPT1XekfgD7UbWf7yttPZH3ZMieaIlA9wXJBt1HwxbJZM/+pJE0TS XU1u2bw+9O0shxJLcUaioRZzUXEiAJYrEYfjAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42I5/e+xgO6dRZ/DDNY2SFq8/3ufzWLhw7vM Fpv6t7JbXPn6ns3i0+pWdoudD3axW0x6+oDN4vKuOWwWrzf9ZXTg9Ni2exurx9/n11k8dtxd wuix99sCFo/Fe14yedzvPs7ksXPSXiaPz5vkAjiiGhhtMlITU1KLFFLzkvNTMvPSbZW8g+Od 403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AOVFIoS8wpBQoFJBYXK+nbYZoQGuKmawHTGKHr GxIE12NkgAYS1jBm9L84xF5wUrzi7uwFbA2Mp4W6GDk5JARMJDoO97NC2GISF+6tZwOxhQSW Mko0bBMAsXkFBCV+TL7H0sXIwcEsIC9x5FI2hKkuMWVKbhcjF1D1A0aJ+0/vsUOUa0lMO9HO AmKzCKhKHHw5iQnEZgOyJ664zwbSKyoQIdF9ohIkLCLgJfFs3lIWkDnMAtuYJLqX9YGdIyxg LtH7sJMV4hxnicv/boPN5BRwkVh6ZzvrBEaBWUium4Vw3SyE6xYwMq9ilEgtSC4oTkrPNcxL LdcrTswtLs1L10vOz93ECE4Cz6R2MB7c5X6IUYCDUYmH9wbX5zAh1sSy4srcQ4wSHMxKIrwb 5wOFeFMSK6tSi/Lji0pzUosPMZoCvTeRWUo0OR+YoPJK4g2NTcyMLI3MDS2MjM2VxHkf/18X JiSQnliSmp2aWpBaBNPHxMEp1cBYcs/sRsrl0K8qV14m32f57F4nIVl39pes9IHCpbcVMiIX hbJaaiyYlJ/QkdxuMYGr8+z1otzpoSdSVvK8KpVXP3/bz3iyu/x14WMuR/KSHqn7av87svr5 FM4vRYfvdnOt3ceWwTK1++L+ryaru7U0dPwP/PU/vjG34Xdnz5kFLnv31utznmVUYinOSDTU Yi4qTgQAYUsfoRgDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2940 Lines: 77 Hi, 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: > From: Gustavo Padovan > > 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(-) >