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 S1752147AbcDZPJu (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Apr 2016 11:09:50 -0400
Received: from mail.fireflyinternet.com ([87.106.93.118]:64135 "EHLO
	fireflyinternet.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org
	with ESMTP id S1751363AbcDZPJt (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2016 11:09:49 -0400
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=78.156.65.138;
Date: Tue, 26 Apr 2016 16:09:39 +0100
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Gustavo Padovan <gustavo@padovan.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        devel@driverdev.osuosl.org, Daniel Stone <daniels@collabora.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Riley Andrews <riandrews@android.com>, dri-devel@lists.freedesktop.org,
        linux-kernel@vger.kernel.org,
        Arve =?iso-8859-1?B?SGr4bm5lduVn?= <arve@android.com>,
        Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
        John Harrison <John.C.Harrison@Intel.com>
Subject: Re: [RFC v2 1/8] dma-buf/fence: add fence_collection fences
Message-ID: <20160426150939.GQ27856@nuc-i3427.alporthouse.com>
Mail-Followup-To: Chris Wilson <chris@chris-wilson.co.uk>,
	Gustavo Padovan <gustavo@padovan.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, Daniel Stone <daniels@collabora.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Riley Andrews <riandrews@android.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Arve =?iso-8859-1?B?SGr4bm5lduVn?= <arve@android.com>,
	Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
	John Harrison <John.C.Harrison@Intel.com>
References: <1461623608-29538-1-git-send-email-gustavo@padovan.org>
 <1461623608-29538-2-git-send-email-gustavo@padovan.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1461623608-29538-2-git-send-email-gustavo@padovan.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote:
> +static const char *fence_collection_get_timeline_name(struct fence *fence)
> +{
> +	return "no context";

"unbound" to distinguish from fence contexts within a timeline?

> +static bool fence_collection_enable_signaling(struct fence *fence)
> +{
> +	struct fence_collection *collection = to_fence_collection(fence);
> +	int i;
> +
> +	for (i = 0 ; i < collection->num_fences ; i++) {
> +		if (fence_add_callback(collection->fences[i].fence,
> +				       &collection->fences[i].cb,
> +				       collection_check_cb_func)) {
> +			atomic_dec(&collection->num_pending_fences);
> +			return false;

Don't stop, we need to enable all the others!

> +		}
> +	}
> +
> +	return !!atomic_read(&collection->num_pending_fences);

Redundant !!

> +}
> +
> +static bool fence_collection_signaled(struct fence *fence)
> +{
> +	struct fence_collection *collection = to_fence_collection(fence);
> +
> +	return (atomic_read(&collection->num_pending_fences) == 0);

Redundant ()

> +static signed long fence_collection_wait(struct fence *fence, bool intr,
> +					 signed long timeout)
> +{

What advantage does this have over fence_default_wait? You enable
signaling on all, then wait sequentially. The code looks redundant and
could just use fence_default_wait instead.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre