Received: by 10.192.165.148 with SMTP id m20csp79608imm; Wed, 9 May 2018 09:05:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZotC02mJiroasJ80R9tVpqw9jrvyMY37N+1DpaSWrKXTo3/3I4kZYvn9YJN1b7espR6/T0s X-Received: by 10.98.18.212 with SMTP id 81mr44681624pfs.243.1525881924696; Wed, 09 May 2018 09:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525881924; cv=none; d=google.com; s=arc-20160816; b=UwtkxBQX2g8pSC059aiqsw9Mqay6Mddr4myOae3VfqBGSbVbYbwI7+M26DKusEDdeR CoYmNc4fvSe5ZVP5bSIrEurjEwlavy0zLkmHuQH35LZjBVZG9tTs0/ToFO/aEmJ2FzX8 +voLBDp2BkeBvU9sMDJh3xl5akZQwMfGHhvXVxWh/e/lmEqEjEkV7QGoQUFaOvWcVITl ReZjwQkZ9ywSWyFACmrO3Vh4b9VNd+VJyczVINbVMmASncL2w3d/+TOoaw4YkDCmwYYU rUitTj2Idd+UGGV1c4gKrEnEiX+VP4rCE2AypBb8IQPXkqa2R88t6guBqO1W92s2zt5e 7ipA== 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:date:cc:to:from:subject :message-id:arc-authentication-results; bh=DbtiPQB5/MYPyIW4ELxDFOp+WLzt7w0DQ/IrQP2P/Bw=; b=yAFlAOGSV+aXB3xdZMiKgiNpTtSlYJU1oXfblDCyBCeOBrI235NXdCrd7OgxooWZN1 6BOV1HPmsIdA+3oxYDZHVIKso1d91EZ5YkqieZMvxpZ+JIiz/NO7bh5SdQTr/Pljp9kj MjrrR9iDjn/0c9rY5r3r7pXRl7DEuAlTevaUi0BKuIxxoolPQTUqu+c78LbOG65UuZlf Iha3uO05thzdEY6t2mmUlD2c+bIz2N3v+B/QWzMMwLWV/1ENEsuiJ0st9Ozpt6qdOYiv obBtcWx6HXLaIaQMLMFqFNtQzsJTEbxJosV1q9BSolAmtSz4UzVJKXgJVylKDpMikbep RH/A== 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=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 68-v6si26608061pla.452.2018.05.09.09.05.00; Wed, 09 May 2018 09:05:24 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965366AbeEIQEk (ORCPT + 99 others); Wed, 9 May 2018 12:04:40 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:56458 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935151AbeEIQEh (ORCPT ); Wed, 9 May 2018 12:04:37 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 8905B2639F6 Message-ID: Subject: Re: [PATCH v9 11/15] vb2: add in-fence support to QBUF From: Ezequiel Garcia To: Brian Starkey Cc: linux-media@vger.kernel.org, kernel@collabora.com, Hans Verkuil , Mauro Carvalho Chehab , Shuah Khan , Pawel Osciak , Alexandre Courbot , Sakari Ailus , linux-kernel@vger.kernel.org, Gustavo Padovan Date: Wed, 09 May 2018 13:03:15 -0300 In-Reply-To: <20180509103639.GC39838@e107564-lin.cambridge.arm.com> References: <20180504200612.8763-1-ezequiel@collabora.com> <20180504200612.8763-12-ezequiel@collabora.com> <20180509103639.GC39838@e107564-lin.cambridge.arm.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-05-09 at 11:36 +0100, Brian Starkey wrote: [..] > > @@ -203,9 +215,14 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, void *pb) > > b->timestamp = ns_to_timeval(vb->timestamp); > > b->timecode = vbuf->timecode; > > b->sequence = vbuf->sequence; > > - b->fence_fd = 0; > > b->reserved = 0; > > > > + b->fence_fd = 0; > > I didn't understand why we're returning 0 instead of -1. Actually the > doc in patch 10 seems to say it will be -1 or 0 depending on whether > we set one of the fence flags? I'm not sure: > > For all other ioctls V4L2 sets this field to -1 if > ``V4L2_BUF_FLAG_IN_FENCE`` and/or ``V4L2_BUF_FLAG_OUT_FENCE`` are set, > otherwise this field is set to 0 for backward compatibility. > Well, I think that for backwards compatibility (userspace not knowing about fence_fd field), we should return 0, unless the flags are explicitly set. That is what the doc says and it sounds sane. The bits are implemented in patch 12, but as I mentioned in my reply to patch 10, I will move it to patch 10, for consistency. Thanks, Eze