Received: by 10.192.165.148 with SMTP id m20csp5344559imm; Wed, 9 May 2018 03:35:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpd3AGs8KuNxKSCMYdN34IHNSQA715OXdQMPNqIDVSazonZ6A22FFfUuOC7T3bNpo5gtQkf X-Received: by 2002:a65:64c4:: with SMTP id t4-v6mr133283pgv.34.1525862151751; Wed, 09 May 2018 03:35:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525862151; cv=none; d=google.com; s=arc-20160816; b=xa0zhG9TFJPw1ZrsFRElnnjJdGC6e4TLcAIff8k39/btdcLKXO6HPg6gu5Zx+Nk+7S /rGJ/kiH6dMgYkWrBij2+br1uk7I31VZhSkWZi3nNXcMoVg9gTrzVZ/wa0m1J1duNlhV mF52xg6sqObOjQRprvKysvCWTSJFyorwgWBaQOLq/KPLqQzBzsl6r5r/nmKeFyigbdxB Ik5eQ+HsTr3/hAy7tRCn7PKI2Qpy8tLmuDc2R1jQyVPQnq4uDsKWHcS0e9roeXK2rIo2 fzYVYxUID0tUZUdT9bTpJCYkG7pBUuiOLFqokl0P+QcmcFRGVaHHP2lkIsuE4ucw3JYt 9TGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=IM4HrsW9xaOYpmQGYp+7kzXgtGE6U7r8tjXglUAzsJE=; b=Z4XNC4eH8sBoVTafkM/FYxaF3abCNLeuMJa3PqkYtvFz/jYEKXZp8eYvsj10cD1suK vWmmB8xkok4k6TS5jKZMdYR0iRKIYinMvbMFjeoMhJuf0a2UBNNTRYXUH3cPzyp+nBaH IiOto3g2eVeOh5geKALmHrEhESKisHAUz1pCPkZxGLbxyU7aLrqQgFKYrDjQLrNWn63G 0wDb+Cqxx1o//B3q5gsLCQzkm+pnqYbDMOlV09iiflVJaEy3ngq0uELFhxR9RS7zAoUr uCcgcaLAk/fyxlXHjezolmc7zhxMeaKEGgp73sQboIGoCRhGXWXAxbAXDJdHIIdoFXZp gQMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 89si26464443pfs.362.2018.05.09.03.35.37; Wed, 09 May 2018 03:35:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934583AbeEIKfK (ORCPT + 99 others); Wed, 9 May 2018 06:35:10 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41938 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933864AbeEIKfJ (ORCPT ); Wed, 9 May 2018 06:35:09 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B51871650; Wed, 9 May 2018 03:35:08 -0700 (PDT) Received: from e107564-lin.cambridge.arm.com (e107564-lin.cambridge.arm.com [10.2.131.9]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C575A3F58C; Wed, 9 May 2018 03:35:06 -0700 (PDT) Date: Wed, 9 May 2018 11:35:05 +0100 From: Brian Starkey To: Gustavo Padovan Cc: Hans Verkuil , Ezequiel Garcia , linux-media@vger.kernel.org, kernel@collabora.com, Mauro Carvalho Chehab , Shuah Khan , Pawel Osciak , Alexandre Courbot , Sakari Ailus , linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 11/15] vb2: add in-fence support to QBUF Message-ID: <20180509103504.GB39838@e107564-lin.cambridge.arm.com> References: <20180504200612.8763-1-ezequiel@collabora.com> <20180504200612.8763-12-ezequiel@collabora.com> <5fd5d7a9-5b74-fe2a-6148-59b90cabb9e8@xs4all.nl> <1525821486.1445.17.camel@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1525821486.1445.17.camel@collabora.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, May 08, 2018 at 08:18:06PM -0300, Gustavo Padovan wrote: > >Hi Hans, > >On Mon, 2018-05-07 at 14:07 +0200, Hans Verkuil wrote: >> On 04/05/18 22:06, Ezequiel Garcia wrote: >> > From: Gustavo Padovan [snip] >> > diff --git a/include/media/videobuf2-core.h >> > b/include/media/videobuf2-core.h >> > index 364e4cb41b10..28ce8f66882e 100644 >> > --- a/include/media/videobuf2-core.h >> > +++ b/include/media/videobuf2-core.h >> > @@ -17,6 +17,7 @@ >> > #include >> > #include >> > #include >> > +#include >> > >> > #define VB2_MAX_FRAME (32) >> > #define VB2_MAX_PLANES (8) >> > @@ -255,12 +256,21 @@ struct vb2_buffer { >> > * done_entry: entry on the list that >> > stores all buffers ready >> > * to be dequeued to userspace >> > * vb2_plane: per-plane information; do not >> > change >> > + * in_fence: fence received from vb2 client >> > to wait on before >> > + * using the buffer (queueing to >> > the driver) >> > + * fence_cb: fence callback information >> > + * fence_cb_lock: protect callback signal/remove >> > */ >> > enum vb2_buffer_state state; >> > >> > struct vb2_plane planes[VB2_MAX_PLANES]; >> > struct list_head queued_entry; >> > struct list_head done_entry; >> > + >> > + struct dma_fence *in_fence; >> > + struct dma_fence_cb fence_cb; >> > + spinlock_t fence_cb_lock; >> > + >> >> So for the _MPLANE formats this is one fence for all planes. Which >> makes sense, but how >> does drm handle that? Also one fence for all planes? > >Yes, this is one fence for all planes. > >The DRM concept for planes is a totally different concept and is >basically a representation of an user definable square on the screen, >and to that plane there in one framebuffer attached - display hw has no >such a multiplanar for the same image AFAICT. So you probably need some >blit to convert the v4l2 multiplanar to a DRM framebuffer. > Lots of display hardware can do multi-planar formats, and there's space in struct drm_framebuffer for up to 4 buffer handles (e.g. 3 handles are passed for Luma, Cr, and Cb when the framebuffer format is DRM_FORMAT_YUV420) - like V4L2 MPLANE. The V4L2 code here matches with the DRM "explicit sync" (IN_FENCE_FD/OUT_FENCE_PTR) stuff, which is probably what we want. The main difference is that in DRM, explicit fences aren't associated with framebuffers, they're associated with the things using the framebuffers - but practically it doesn't make a difference. There can be per-buffer "implicit sync" via dma-buf reservation objects, but I don't think this series should attempt to deal with that. Cheers, -Brian >> >> I think there should be a comment about this somewhere. > >Yes, we've been over this exact discussion a few times :) >Having entirely different things with the same name is quite confusing. > >Regards, > >Gustavo > >-- >Gustavo Padovan >Principal Software Engineer >Collabora Ltd.