Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752636AbcDZQ01 (ORCPT ); Tue, 26 Apr 2016 12:26:27 -0400 Received: from mga01.intel.com ([192.55.52.88]:7399 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752014AbcDZQ00 (ORCPT ); Tue, 26 Apr 2016 12:26:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,537,1455004800"; d="scan'208";a="692589070" Date: Tue, 26 Apr 2016 19:26:21 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Gustavo Padovan , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Message-ID: <20160426162621.GU4329@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> <20160426143635.GW8291@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: <20160426143635.GW8291@phenom.ffwll.local> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1405 Lines: 31 On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote: > On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote: > > 2016-04-26 Ville Syrj?l? : > > > > > On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote: > > > > From: Gustavo Padovan > > > > > > > > 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. However the FENCE_FD property is easier to > > handle in userspace than the array. Any other idea? > > Imo FENCE_FD is perfectly fine. But what's the concern around giving > people the wrong idea with attaching fences to planes? For nonblocking > commits we need to store them somewhere for the worker, drm_plane_state > seems like an as good place as any other. It gives the impression that each plane might flip as soon as its fence signals. -- Ville Syrj?l? Intel OTC