From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Date: Tue, 26 Apr 2016 19:25:26 +0300 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-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <20160426141422.GG7857@joana> Sender: linux-kernel-owner@vger.kernel.org To: Gustavo Padovan Cc: Gustavo Padovan , Daniel Stone , Daniel Vetter , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison List-Id: dri-devel@lists.freedesktop.org On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote: > 2016-04-26 Ville Syrj=E4l=E4 : >=20 > > On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > >=20 > > > There is now a new property called FENCE_FD attached to every pla= ne > > > state that receives the sync_file fd from userspace via the atomi= c commit > > > IOCTL. > >=20 > > I still don't like this property abuse. Also with atomic, all passe= d > > fences must be waited upon before anything is done, so attaching th= em > > to planes seems like it might just give people the wrong idea. >=20 > 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 l= ike > 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? >=20 > Gustavo --=20 Ville Syrj=E4l=E4 Intel OTC