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 S1752623AbcDZQZh (ORCPT <rfc822;w@1wt.eu>);
	Tue, 26 Apr 2016 12:25:37 -0400
Received: from mga02.intel.com ([134.134.136.20]:8887 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752249AbcDZQZf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 26 Apr 2016 12:25:35 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.24,537,1455004800"; 
   d="scan'208";a="940624921"
Date: Tue, 26 Apr 2016 19:25:26 +0300
From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
To: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Gustavo Padovan <gustavo@padovan.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>,
        John Harrison <John.C.Harrison@Intel.com>
Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support
Message-ID: <20160426162526.GT4329@intel.com>
References: <1461623608-29538-1-git-send-email-gustavo@padovan.org>
 <1461623608-29538-6-git-send-email-gustavo@padovan.org>
 <20160426101050.GN4329@intel.com>
 <20160426141422.GG7857@joana>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160426141422.GG7857@joana>
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

On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote:
> 2016-04-26 Ville Syrjälä <ville.syrjala@linux.intel.com>:
> 
> > On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> > > 
> > > There is now a new property called FENCE_FD attached to every plane
> > > state that receives the sync_file fd from userspace via the atomic commit
> > > IOCTL.
> > 
> > I still don't like this property abuse. Also with atomic, all passed
> > fences must be waited upon before anything is done, so attaching them
> > to planes seems like it might just give people the wrong idea.
> 
> I'm actually fine with this as property, but another solutions is use
> an array of {plane, fence_fd} and extend drm_atomic_ioctl args just like
> we have done for out fences.

Why do you want to associate these with planes?

> However the FENCE_FD property is easier to
> handle in userspace than the array. Any other idea?
> 
> 	Gustavo

-- 
Ville Syrjälä
Intel OTC