From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755262AbcCXHU5 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 24 Mar 2016 03:20:57 -0400
Received: from mga01.intel.com ([192.55.52.88]:15885 "EHLO mga01.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753783AbcCXHUt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 24 Mar 2016 03:20:49 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,383,1455004800"; 
   d="scan'208";a="930714852"
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
To: Gustavo Padovan <gustavo@padovan.org>, dri-devel@lists.freedesktop.org
References: <1458758847-21170-1-git-send-email-gustavo@padovan.org>
Cc: linux-kernel@vger.kernel.org, Daniel Stone <daniels@collabora.com>,
        =?UTF-8?Q?Arve_Hj=c3=b8nnev=c3=a5g?= <arve@android.com>,
        Riley Andrews <riandrews@android.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Rob Clark <robdclark@gmail.com>, Greg Hackmann <ghackmann@google.com>,
        John Harrison <John.C.Harrison@Intel.com>,
        Gustavo Padovan <gustavo.padovan@collabora.co.uk>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Message-ID: <56F3954D.8000308@linux.intel.com>
Date: Thu, 24 Mar 2016 08:20:45 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <1458758847-21170-1-git-send-email-gustavo@padovan.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hey,

Op 23-03-16 om 19:47 schreef 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
>
> /**
>  * 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
>
Why did you choose to add fence_collection, rather than putting sync_file in state?

There used to be a sync_fence_wait function, which would mean you'd have everything you need.

~Maarten