Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp6242072rwl; Wed, 22 Mar 2023 08:11:09 -0700 (PDT) X-Google-Smtp-Source: AK7set9y9Ry1S5JhAUvxAnTISknctgza/6UErKRqm8OZ9lqzhxWQDjL0KiwvpTUWnozc0udc9gbD X-Received: by 2002:a17:906:9753:b0:931:4b0b:73e3 with SMTP id o19-20020a170906975300b009314b0b73e3mr10244883ejy.65.1679497869116; Wed, 22 Mar 2023 08:11:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679497869; cv=none; d=google.com; s=arc-20160816; b=xR6W7mhgJ0HH/RjleABypOVw8uAFwArdOSz8vAtN9qqx+AZrhwyt3/qYi31eV5aIoC Q9mfP9ixCUZfs3tPLFY5YhmwFpa/PEQWJsrhQ/G8sN7kcRJExI/QSSgjIkGaTa5CGMcB 9+NY+LTi2TVVMBkQW7+vIiDEk7oiWcwxSDXCJEbnNLRT94OFyPUY5eSoPZazcPRJcJsg MwEYTxIym9sgMBUfmy+FInt/6M4hPldqQ9r33MTyEB4lySW+owofpfQVxDv0c0UqgTWP aWaWEqsLlZGrqMN0frnezqSufCKbyNHXKc8DAP4iYRg3LKswNAJvoNzgQa9EBpBjncEB dGhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=nIOsra+dyZwSVbueOIgO3BNhnbCGUais9sT7b43tefc=; b=rsC6DMl1negsSHmwSKEcuGBS34mhH74fssAOKZ266kpPV1fifdG9gzZjWjV8WLUtBU ty3CARDBxJ4UUrJq6vR6LHkD2JayrETIZwfFjmoo2ShxR1vzz/oNduhaqXlKkKEGo5GB 3HyQYC+jdsYKPv85CqtWZbFLqyqxku8GlReIwvKxbXBesdN+ksCuG3iyHMP7VcKuJuUd /rN+uSC9vVVfWef7GJutg4L4ihOQN+n/JMSKb4YUxFNvqv6T6743NgpOOsnDAWICEL4A 3NjIsNJaWA5jaUN2a+GLc03CSoEc1Gv/v6m1zhdsCXa9lXQ99ieVFhbybEJPkAlW9Fyx mtxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=WKXlws0Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fy37-20020a1709069f2500b00939a099eb36si4385393ejc.781.2023.03.22.08.10.44; Wed, 22 Mar 2023 08:11:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=WKXlws0Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230209AbjCVPBw (ORCPT + 99 others); Wed, 22 Mar 2023 11:01:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229482AbjCVPBv (ORCPT ); Wed, 22 Mar 2023 11:01:51 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FCAB11643; Wed, 22 Mar 2023 08:01:50 -0700 (PDT) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 5B113BC1; Wed, 22 Mar 2023 16:01:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1679497307; bh=Az9CmcJ+XBb4olbWe91Aj3r8+M/Mn03lE84beJHYWcQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WKXlws0YL/fxPG1M5ZQGaWla8QrHlrOYNJMXI2o/UFolpE4TobnpdShV9cjraTqeO MwA6homUVXpEZ5ca7dTz/vAQQhQlSiv7sA8a4cprGocH5iNqqFk8jBFOGn1mJ3u5mP wimrpwmLpPfLk6YPVwEV2dY/f3itqV+8uUElZbK8= Date: Wed, 22 Mar 2023 17:01:53 +0200 From: Laurent Pinchart To: Nicolas Dufresne Cc: Hans Verkuil , David Laight , Benjamin Gaignard , "tfiga@chromium.org" , "m.szyprowski@samsung.com" , "mchehab@kernel.org" , "ming.qian@nxp.com" , "shijie.qin@nxp.com" , "eagle.zhou@nxp.com" , "bin.liu@mediatek.com" , "matthias.bgg@gmail.com" , "angelogioacchino.delregno@collabora.com" , "tiffany.lin@mediatek.com" , "andrew-ct.chen@mediatek.com" , "yunfei.dong@mediatek.com" , "stanimir.k.varbanov@gmail.com" , "quic_vgarodia@quicinc.com" , "agross@kernel.org" , "andersson@kernel.org" , "konrad.dybcio@linaro.org" , "ezequiel@vanguardiasur.com.ar" , "p.zabel@pengutronix.de" , "daniel.almeida@collabora.com" , "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" , "kernel@collabora.com" Subject: Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list Message-ID: <20230322150153.GO20234@pendragon.ideasonboard.com> References: <20230313135916.862852-1-benjamin.gaignard@collabora.com> <20230313135916.862852-3-benjamin.gaignard@collabora.com> <20230313181155.GC22646@pendragon.ideasonboard.com> <86df05244d974416903e919d387a0a0b@AcuMS.aculab.com> <20230319233358.GD20234@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 22, 2023 at 10:50:52AM -0400, Nicolas Dufresne wrote: > Hi Laurent, > > Le lundi 20 mars 2023 à 01:33 +0200, Laurent Pinchart a écrit : > > > The typical usage is that applications allocate N buffers with the > > > VIDIOC_REQBUFS ioctl, and in most cases that's all they use. > > > > Note that once we get DELETE_BUF (or DELETE_BUFS) support I'd like to > > encourage applications to use the new API, and deprecate REQBUFS > > (dropping it isn't on my radar, as it would take forever before no > > userspace uses it anymore). > > I was wondering if you can extend on this. I'm worried the count semantic might > prevent emulating it over create_bufs() ops, but if that works, did you meant to > emulate it so driver no longer have to implement reqbufs() if they have > create_bufs() ? For drivers it should be fairly simply, as the reqbufs and create_bufs ioctl handlers should just point to the corresponding videobuf2 helpers. What I meant is that I'd like to encourage userspace to use the VIDIOC_CREATE_BUFS ioctl instead of VIDIOC_REQBUFS. -- Regards, Laurent Pinchart