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 S1752575AbcDZPCV (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Apr 2016 11:02:21 -0400
Received: from bhuna.collabora.co.uk ([46.235.227.227]:45313 "EHLO
	bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751815AbcDZPCT convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2016 11:02:19 -0400
Date: Tue, 26 Apr 2016 12:02:08 -0300
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
To: Gustavo Padovan <gustavo@padovan.org>, linux-kernel@vger.kernel.org,
        dri-devel@lists.freedesktop.org, Daniel Stone <daniels@collabora.com>,
        Arve =?iso-8859-1?B?SGr4bm5lduVn?= <arve@android.com>,
        Riley Andrews <riandrews@android.com>, Rob Clark <robdclark@gmail.com>,
        Greg Hackmann <ghackmann@google.com>,
        John Harrison <John.C.Harrison@Intel.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Sumit Semwal <sumit.semwal@linaro.org>
Subject: Re: [RFC v2 1/8] dma-buf/fence: add fence_collection fences
Message-ID: <20160426150208.GJ7857@joana>
References: <1461623608-29538-1-git-send-email-gustavo@padovan.org>
 <1461623608-29538-2-git-send-email-gustavo@padovan.org>
 <20160426144102.GX8291@phenom.ffwll.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
In-Reply-To: <20160426144102.GX8291@phenom.ffwll.local>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

2016-04-26 Daniel Vetter <daniel@ffwll.ch>:

> On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> > 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.
> > 
> > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> 
> FENCE_NO_CONTEXT semantics needs an ack from amdgpu maintainers. I'm not
> entirely sure they might not hit the new WARN_ON by accident now. Please
> cc Alex Deucher & Christian König.

Sure, I'll Cc then in the revision. But if they use
fence_context_alloc() to get the context they should never hit any
WARN_ON as context numbers now starts at 1. 0 is reserved for
FENCE_NO_CONTEXT.

	Gustavo