Received: by 10.223.164.202 with SMTP id h10csp931739wrb; Fri, 17 Nov 2017 11:01:05 -0800 (PST) X-Google-Smtp-Source: AGs4zMa9USIIMSlER5QaMxFPbo6O/6vh9RAVv1DNi41Fn2B2dU0sDui0RZFBtU2ax4UJkaCNy3IK X-Received: by 10.101.92.66 with SMTP id v2mr5918465pgr.151.1510945265144; Fri, 17 Nov 2017 11:01:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510945265; cv=none; d=google.com; s=arc-20160816; b=VnG3+EvBlTaWo0xwXcglgLxHFeSoZQioq6/WUJpldV0AKHNDbiVijiSDXypa0w33fG PFbUzMRXoAyQGv5vUnOkgPumYD4CUIsyhfBoQan3zbBS7UoBbUGJPh+j5VrZkVgL7m4i BYUxYNBJlzTS3pqCcy65bhBtkVbL/H9az4+n0JkAAAFJCaZ/FiPoMBgFO23sKFAdh4X5 Qwc98z4dRV9zW/y7ZjsYXiYjS9DyKuvqk4vb435AIPk84njkaRMz83wTjtzTzrepOqR1 6CHnuSG/Jl+fwsuU8zcGFty6gueBAv5zMfEaI5LHTGIjAKs7t+1W8CpffnUX6Dthvp++ +UBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=H3DNGi/J+iAdDtZOXL6sMQQ4rMf8CqH0x4e2xE1nQ8s=; b=R8LCu3QgM01alBJZMAGQz02IfnmkwCQSS4PZVjSJd4Skcq5uJEqtupY40wD5JASX6l FmyJImNYTZIJA1T4Nc5+vqEM/Wh2ujCeJ4Cor1v2eN0x5rFpXDXunz8/JOcMpf39uz1q RR8ZBVmxS0KX8O3N2YS/v/Hci4j9SWUjG3NzKjB81a8p5Kwy9XCR6eUprYEW2+TWka2z IQHat1uaurs7r+auNGhT57WgYQ+FpSDLmf6NfUtbVRlgiEDh9g1dt2MX3nMVO/8sKqKj ogG3VjnccHYSHTeqjvO0nTyds4pHK0D+932v479aKvN5wkjMt7FCosnLAx3aIt306tXw X0yg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=samsung.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e22si3101870pgv.360.2017.11.17.11.00.51; Fri, 17 Nov 2017 11:01:05 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030223AbdKQNsI (ORCPT + 92 others); Fri, 17 Nov 2017 08:48:08 -0500 Received: from osg.samsung.com ([64.30.133.232]:56440 "EHLO osg.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933663AbdKQNr6 (ORCPT ); Fri, 17 Nov 2017 08:47:58 -0500 Received: from localhost (localhost [127.0.0.1]) by osg.samsung.com (Postfix) with ESMTP id 274E22B65E; Fri, 17 Nov 2017 05:47:58 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at dev.s-opensource.com Received: from osg.samsung.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M-z0KNGxoMz; Fri, 17 Nov 2017 05:47:56 -0800 (PST) Received: from vento.lan (177.17.214.168.dynamic.adsl.gvt.net.br [177.17.214.168]) by osg.samsung.com (Postfix) with ESMTPSA id CD0512B653; Fri, 17 Nov 2017 05:47:53 -0800 (PST) Date: Fri, 17 Nov 2017 11:47:51 -0200 From: Mauro Carvalho Chehab To: Gustavo Padovan Cc: linux-media@vger.kernel.org, Hans Verkuil , Shuah Khan , Pawel Osciak , Alexandre Courbot , Sakari Ailus , Brian Starkey , Thierry Escande , linux-kernel@vger.kernel.org, Gustavo Padovan Subject: Re: [RFC v5 07/11] [media] vb2: add in-fence support to QBUF Message-ID: <20171117114751.2dc10542@vento.lan> In-Reply-To: <20171117131248.GI19033@jade> References: <20171115171057.17340-1-gustavo@padovan.org> <20171115171057.17340-8-gustavo@padovan.org> <20171117105351.3bb0af32@vento.lan> <20171117131248.GI19033@jade> Organization: Samsung X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, 17 Nov 2017 11:12:48 -0200 Gustavo Padovan escreveu: > > > /* > > > * If streamon has been called, and we haven't yet called > > > * start_streaming() since not enough buffers were queued, and > > > * we now have reached the minimum number of queued buffers, > > > * then we can finally call start_streaming(). > > > - * > > > - * If already streaming, give the buffer to driver for processing. > > > - * If not, the buffer will be given to driver on next streamon. > > > */ > > > if (q->streaming && !q->start_streaming_called && > > > - q->queued_count >= q->min_buffers_needed) { > > > + __get_num_ready_buffers(q) >= q->min_buffers_needed) { > > > > I guess the case where fences is not used is not covered here. > > > > You probably should add a check at __get_num_ready_buffers(q) > > as well, making it just return q->queued_count if fences isn't > > used. > > We can't know that beforehand, some buffer ahead may have a fence, > but there is already a check for !fence for each buffer. If none of > them have fences the return will be equal to q->queued_count. Hmm... are we willing to support the case where just some buffers have fences? Why? In any case, we should add a notice at the documentation telling about what happens if not all buffers have fences, and if fences are required to be setup before starting streaming, or if it is possible to dynamically change the fances behavior while streaming. -- Thanks, Mauro From 1584340618310018009@xxx Fri Nov 17 18:55:56 +0000 2017 X-GM-THRID: 1584155088810136583 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread