Message ID | 20231012114642.19040-41-benjamin.gaignard@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp1165792vqb; Thu, 12 Oct 2023 04:49:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFNc5i2y94+t3WeQJ40ZURkHyD5mIojrK61UXr9j3hcu9jyVC5ezRjLo1IAFvQn8Eun8Dsn X-Received: by 2002:a05:6e02:60a:b0:34f:7ba2:50e8 with SMTP id t10-20020a056e02060a00b0034f7ba250e8mr23509334ils.2.1697111378863; Thu, 12 Oct 2023 04:49:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697111378; cv=none; d=google.com; s=arc-20160816; b=y0QHb7ZnjM+dX76FOWfr5TDvMtHpa3oF4jHBhW5WhBhHBWJw4Grotrnify5ELVaYEN KJiWXkVs8yUmp+DbYGrv3LywjjLmqRQiFfRA/o5q/ZUYj05+E1NNnFD9p1PQS5cY0AsJ 10GAquND+3AK8sifSDVl8GIaU4QIie1OLhCNg/tmRkxGv5RZhis5NBHZgHGX54PON+tS UPs8anuJTUpK+q3QCNlVJ13gZl//39TDY0QGNdc26wYGb5tG8SSuqPhj0Xi8GDCvTz4j /hyN81yVzFQqxM4p9Al0kqoH30vsWtshXN/acl2iuIKPvI71yVQRz1CKvohtCrzHFeY0 JcuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=tNAbg+knkabZcIfZKYQJcMQ9aVj2QfkLtg7kl/Xz8lA=; fh=ceA81l8d2hZW6pWH7VE5TwJxtgXUzAubfWIMcikPA1M=; b=Xf31QwFLsCEF5ovLq68iRVG7AVmgDQSp62r8/rHxnNfeKvbJ9Kyv+h1237o93lyzFW qHoZRmXvd098qskTdtD3DCvpreAyJyyfwnQyx7DmMxo0P0MQQ93ujuBRc7b/xbVwTcUu lIFY0ZUAaIC+bPHLHnHrqK5R+iw+KSFNHw81OqUWVsVDvrk0V+h2oosatlUIRZRHQjLK QB1/zTS3KqWl1X2fmZL1HWCX45bAUzp367QhjRnfcpyFDy9Z0Ph7IHbMUaZDbbOFiSaf jizjMmmdmCEaLO6Hk5+g2tM0DtBQzhc3GE8pp83M4SP4k7GgA2/diB/+aThPiRCiaP0X NJIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Z4bQsHlw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id 131-20020a630289000000b0055785a37147si2042490pgc.590.2023.10.12.04.49.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Oct 2023 04:49:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Z4bQsHlw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 16938822CECD; Thu, 12 Oct 2023 04:49:38 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379265AbjJLLtg (ORCPT <rfc822;rua109.linux@gmail.com> + 19 others); Thu, 12 Oct 2023 07:49:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1378970AbjJLLre (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 12 Oct 2023 07:47:34 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C679DB; Thu, 12 Oct 2023 04:47:12 -0700 (PDT) Received: from benjamin-XPS-13-9310.. (unknown [IPv6:2a01:e0a:120:3210:7ae7:b86d:c19a:877e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: benjamin.gaignard) by madras.collabora.co.uk (Postfix) with ESMTPSA id AE3C8660739A; Thu, 12 Oct 2023 12:47:10 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1697111231; bh=ph7BpDmTndhVgQkibEyHEMgMXbFU1u8TVxC65OSPSxg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z4bQsHlwdarOoSvvE0kmFcZznJwFUJhIuX+KgZunxJkgDfXOPlDHVX44ksW3y/PI2 C4TXV6ACmIscGmOvecjSzPEufYgt1c8VGw/s2WirKIlFqriJQ7bzTQ5G8fGOJoBK9o h2mLve2mjj6ddLPZVv+RdsNvkMnkAJPH3k6oEkIcG8t6v2HCLxDhiTTQs/i9l2CXRH guf506zU5PWhuvJvMAxLFzykRNfboNOq5eLathYpb8LGwtXShfDfmkYocbKwBqE/3t A8t1emGuE7C+0aWB0uFvTHpebv/iRK+6cy5YQqw2x3GYg7rcG0AsY8wMJhJMMZGqgJ Gp49iEjaDVjIQ== From: Benjamin Gaignard <benjamin.gaignard@collabora.com> To: mchehab@kernel.org, tfiga@chromium.org, m.szyprowski@samsung.com, ming.qian@nxp.com, ezequiel@vanguardiasur.com.ar, p.zabel@pengutronix.de, gregkh@linuxfoundation.org, hverkuil-cisco@xs4all.nl, nicolas.dufresne@collabora.com Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, kernel@collabora.com, Benjamin Gaignard <benjamin.gaignard@collabora.com> Subject: [PATCH v11 40/56] sample: v4l: Stop direct calls to queue num_buffers field Date: Thu, 12 Oct 2023 13:46:26 +0200 Message-Id: <20231012114642.19040-41-benjamin.gaignard@collabora.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20231012114642.19040-1-benjamin.gaignard@collabora.com> References: <20231012114642.19040-1-benjamin.gaignard@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 12 Oct 2023 04:49:38 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779550260867119724 X-GMAIL-MSGID: 1779550260867119724 |
Series |
Add DELETE_BUF ioctl
|
|
Commit Message
Benjamin Gaignard
Oct. 12, 2023, 11:46 a.m. UTC
Use vb2_get_num_buffers() to avoid using queue num_buffers field directly.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
---
samples/v4l/v4l2-pci-skeleton.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Comments
On 12/10/2023 13:46, Benjamin Gaignard wrote: > Use vb2_get_num_buffers() to avoid using queue num_buffers field directly. > > Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> > --- > samples/v4l/v4l2-pci-skeleton.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/samples/v4l/v4l2-pci-skeleton.c b/samples/v4l/v4l2-pci-skeleton.c > index a61f94db18d9..a65aa9d1e9da 100644 > --- a/samples/v4l/v4l2-pci-skeleton.c > +++ b/samples/v4l/v4l2-pci-skeleton.c > @@ -155,6 +155,7 @@ static int queue_setup(struct vb2_queue *vq, > unsigned int sizes[], struct device *alloc_devs[]) > { > struct skeleton *skel = vb2_get_drv_priv(vq); > + unsigned int q_num_bufs = vb2_get_num_buffers(vq); > > skel->field = skel->format.field; > if (skel->field == V4L2_FIELD_ALTERNATE) { > @@ -167,8 +168,8 @@ static int queue_setup(struct vb2_queue *vq, > skel->field = V4L2_FIELD_TOP; > } > > - if (vq->num_buffers + *nbuffers < 3) > - *nbuffers = 3 - vq->num_buffers; > + if (q_num_bufs + *nbuffers < 3) > + *nbuffers = 3 - q_num_bufs; This should be dropped, and instead update q->min_buffers_needed from 2 to 3. Regards, Hans > > if (*nplanes) > return sizes[0] < skel->format.sizeimage ? -EINVAL : 0;
On 16/10/2023 10:23, Hans Verkuil wrote: > On 12/10/2023 13:46, Benjamin Gaignard wrote: >> Use vb2_get_num_buffers() to avoid using queue num_buffers field directly. >> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> >> --- >> samples/v4l/v4l2-pci-skeleton.c | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/samples/v4l/v4l2-pci-skeleton.c b/samples/v4l/v4l2-pci-skeleton.c >> index a61f94db18d9..a65aa9d1e9da 100644 >> --- a/samples/v4l/v4l2-pci-skeleton.c >> +++ b/samples/v4l/v4l2-pci-skeleton.c >> @@ -155,6 +155,7 @@ static int queue_setup(struct vb2_queue *vq, >> unsigned int sizes[], struct device *alloc_devs[]) >> { >> struct skeleton *skel = vb2_get_drv_priv(vq); >> + unsigned int q_num_bufs = vb2_get_num_buffers(vq); >> >> skel->field = skel->format.field; >> if (skel->field == V4L2_FIELD_ALTERNATE) { >> @@ -167,8 +168,8 @@ static int queue_setup(struct vb2_queue *vq, >> skel->field = V4L2_FIELD_TOP; >> } >> >> - if (vq->num_buffers + *nbuffers < 3) >> - *nbuffers = 3 - vq->num_buffers; >> + if (q_num_bufs + *nbuffers < 3) >> + *nbuffers = 3 - q_num_bufs; > > This should be dropped, and instead update q->min_buffers_needed from > 2 to 3. Actually, that's not quite true. I realized that there is a subtle bug in the vb2 core and a general misunderstanding of min_buffers_needed in a lot of drivers. The min_buffers_needed field describes the minimum number of buffers needed before the DMA engine can start. This is typically 0, 1 or 2. Once that many buffers have been queued, then start_streaming callback is called. With fewer buffers queued the DMA engine cannot start, so this represents a DMA engine limitation. Currently vb2 also uses this field as the minimum number of buffers to allocate. However, that should be one more, so min_buffers_needed+1: 'min_buffers_needed' buffers are in-flight, and you need one more that is owned by userspace, otherwise you would never be able to dequeue a buffer if you only created 'min_buffers_needed' buffers. But I noticed a lot of drivers that misinterpret this value as 'the minimum number of buffers to allocate', unrelated to any DMA engine limitations. This is most likely a bug, since this would unnecessarily delay the call to start_streaming(). In other words, it is a mess. I think my earlier advice to change min_buffers_needed and drop the check in queue_setup should be disregarded. If the min_buffers_needed value is >= the value checked in queue_setup, then you can drop the check. In all other cases it is safer to keep it. So in other words, this patch is fine. But e.g. patch 21 needs to keep the check (although with a fix: *nbuffers = 2 - q_num_bufs). When this work is done, then I think I need to take a close review at all the drivers that set min_buffers_needed and/or check the number of buffers in queue_setup and fix it properly. Likely we need two different fields: one for the minimum number of buffers that need to be allocated, and one for the minimum number of buffers that need to be queued before start_streaming can be called. But that raises the question how the 'minimum number of buffers that need to be allocated' would interact with deleting buffers. It's actually not all that easy. Regards, Hans > > Regards, > > Hans > >> >> if (*nplanes) >> return sizes[0] < skel->format.sizeimage ? -EINVAL : 0; >
diff --git a/samples/v4l/v4l2-pci-skeleton.c b/samples/v4l/v4l2-pci-skeleton.c index a61f94db18d9..a65aa9d1e9da 100644 --- a/samples/v4l/v4l2-pci-skeleton.c +++ b/samples/v4l/v4l2-pci-skeleton.c @@ -155,6 +155,7 @@ static int queue_setup(struct vb2_queue *vq, unsigned int sizes[], struct device *alloc_devs[]) { struct skeleton *skel = vb2_get_drv_priv(vq); + unsigned int q_num_bufs = vb2_get_num_buffers(vq); skel->field = skel->format.field; if (skel->field == V4L2_FIELD_ALTERNATE) { @@ -167,8 +168,8 @@ static int queue_setup(struct vb2_queue *vq, skel->field = V4L2_FIELD_TOP; } - if (vq->num_buffers + *nbuffers < 3) - *nbuffers = 3 - vq->num_buffers; + if (q_num_bufs + *nbuffers < 3) + *nbuffers = 3 - q_num_bufs; if (*nplanes) return sizes[0] < skel->format.sizeimage ? -EINVAL : 0;