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 S932350AbcEROa0 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 18 May 2016 10:30:26 -0400
Received: from bhuna.collabora.co.uk ([46.235.227.227]:44348 "EHLO
	bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753286AbcEROaZ convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 18 May 2016 10:30:25 -0400
Date: Wed, 18 May 2016 11:30:11 -0300
From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
To: Christian =?iso-8859-1?Q?K=F6nig?= <christian.koenig@amd.com>
Cc: Gustavo Padovan <gustavo@padovan.org>, dri-devel@lists.freedesktop.org,
        linux-kernel@vger.kernel.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>,
        laurent.pinchart@ideasonboard.com, seanpaul@google.com,
        marcheu@google.com, m.chehab@samsung.com,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Subject: Re: [RFC 1/8] dma-buf/fence: add fence_collection fences
Message-ID: <20160518143011.GA2287@joana>
References: <1460683781-22535-1-git-send-email-gustavo@padovan.org>
 <1460683781-22535-2-git-send-email-gustavo@padovan.org>
 <20160415080254.GQ2510@phenom.ffwll.local>
 <5710AE61.9040308@amd.com>
 <20160415182750.GA23954@joana>
 <20160415192550.GZ2510@phenom.ffwll.local>
 <573C14C3.8080604@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
In-Reply-To: <573C14C3.8080604@amd.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Christian,

2016-05-18 Christian König <christian.koenig@amd.com>:

> Am 15.04.2016 um 21:25 schrieb Daniel Vetter:
> > On Fri, Apr 15, 2016 at 11:27:50AM -0700, Gustavo Padovan wrote:
> > > 2016-04-15 Christian König <christian.koenig@amd.com>:
> > > > Amdgpu also has an implementation for a fence collection which uses a a
> > > > hashtable to keep the fences grouped by context (e.g. only the latest fence
> > > > is keept for each context). See amdgpu_sync.c for reference.
> > > > 
> > > > We should either make the collection similar in a way that you can add as
> > > > many fences as you want (like the amdgpu implementation) or make it static
> > > > and only add a fixed number of fences right from the beginning.
> > > > 
> > > > I can certainly see use cases for both, but if you want to stick with a
> > > > static approach you should probably call the new object fence_array instead
> > > > of fence_collection and do as Daniel suggested.
> > > Maybe we can go for something in between. Have fence_collection_init()
> > > need at least two fences to create the fence_collection. Then
> > > fence_collection_add() would add more dinamically.
> > The problem with adding fences later on is that it makes it trivial to add
> > deadlocks and loops. Just add the fence collection to itself, boom. From
> > that pov it's an unsafe api, and hence something to avoid.
> > -Daniel
> 
> Any conclusion on this? Did any version of the patch made it upstream?
> 
> I'm in the need of an array based fence collection right now as well. Any
> objection that I just take the patch proposed here and fix the comments or
> are you still else working on this right now?

I have a new version of this patch that I didn't send upstream yet
because it is part of a bigger patchset. But I can split it and send
what I have for fence_collection later today.

	Gustavo