Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1266181rwl; Fri, 24 Mar 2023 08:18:06 -0700 (PDT) X-Google-Smtp-Source: AKy350Yx6JtIwN9OwSGOtpBYZGr7lH1uFYSQGrlRig905WuBlpdDMwswE8PR4wAbTrsxg2G1ciFK X-Received: by 2002:aa7:8bdc:0:b0:625:dc2e:9db2 with SMTP id s28-20020aa78bdc000000b00625dc2e9db2mr3288413pfd.4.1679671086026; Fri, 24 Mar 2023 08:18:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679671086; cv=none; d=google.com; s=arc-20160816; b=OWdaLFwin9eU3m9SJrfkGCfyqmh2UzPipFP+iRyZ3bZ575WRHNDMwoSGpfOVdKYjXN 6y26g5kq/cNogK8AvvNB/ryfIw+UD26sE1AdTVGpYHHyB10iOHPUXnYmkU5kZYaroyZZ Zb4whTRLZyaJ8ZyJtOf4azxuKwi+0OzN6T5F4SlMiOzatDdpN3kuMhuMMBmHjC/DH3jS PqePUTvLbbrV8j5HO334WGKrfvQnXxbbV6PTyJDUPd8zg7vJmTf5genTBBytCMJA5OMt bGMnf1bwBG+gy9GgV6JW77dVHxKFRlPhkfM0A5JXDs7jbpM3HNj3qNVt/dHg8uVQ1ii2 jYMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:dkim-signature; bh=BlgJl6q6nmXLwoducihQkeA4VjkQWrKTU/XpmLER5K8=; b=dzuv9u8DUPGbfD4edoBFpX0mgQVkvHtSCYrvNxuSbjjZBGqlCy3UF/PUUKH5dnEUfe RbS5o2JThLCTkMpsmPR7gn476EzxmT1TyWrVP+61vs2hWhVJsGVZ8Xd4e0bBZAtUTXEz g6B+JKdQJgTBZRER+AI/kmU7SR9dL01oo7NCMT/72ZulJmOhhoi/Pnw0/1AkoYaHfnoR /Mrqvqs+qnxAa/IcnUYDZeAErfcca/3AsKfu6V3afkh2viV95T8QgJygmV/Q35g48w2Z UjOBT/VCZc/sYM+hUsFb635rTny1mX/jWRH+SCGhPyTX+RdfZHibK6+GTzyk71lyiwCJ gWfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ndufresne-ca.20210112.gappssmtp.com header.s=20210112 header.b=QAEyb3y2; 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 w10-20020a056a0014ca00b005a8cf0d93cbsi22538628pfu.3.2023.03.24.08.17.53; Fri, 24 Mar 2023 08:18:05 -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 header.i=@ndufresne-ca.20210112.gappssmtp.com header.s=20210112 header.b=QAEyb3y2; 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 S231833AbjCXPPg (ORCPT + 99 others); Fri, 24 Mar 2023 11:15:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231236AbjCXPP1 (ORCPT ); Fri, 24 Mar 2023 11:15:27 -0400 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8BC11F48C for ; Fri, 24 Mar 2023 08:14:59 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id c19so1719282qtn.13 for ; Fri, 24 Mar 2023 08:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20210112.gappssmtp.com; s=20210112; t=1679670894; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=BlgJl6q6nmXLwoducihQkeA4VjkQWrKTU/XpmLER5K8=; b=QAEyb3y2Vs1mSwY136+bu6SS016Otbf3KKfs9Mlyynm1gBzKn8IBg7DKKBORGVgyRL Wz6AisMNEwAkdbvXM7zJ93PyYVnHMRLt+SqV2+KIzgZGBKfSEA/SvYbGi1DbKwG8+t3X EnXZZz4q60ZBfI96mKWDnSZ2+1OtBHBRk9yySy0hupZdJ1YJ07CTHjT6hQzPp0un5Zi4 ZMc2Z4n2f2EN3LAB+6ExoNkdtMUvrlZM9biFAE3RvcusV/CPEzZ0QodUUN6PBVj+S7q1 VeHHAUt7o/Jx+ffoh+LeHf8+aj5khtrxdEJIKejig4N0viMRuvBtbR/GYyPRluiAV9Ca /PWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679670894; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=BlgJl6q6nmXLwoducihQkeA4VjkQWrKTU/XpmLER5K8=; b=5a2ZHkpNbyayvmhYgN639ViIkBtU6ODx7EWf2HxEyFZCu4jQWHRVghGiMZd8Ojkng/ HhGYnMjtaAfyGNrTXUuD/IAW12SPgvn2F1Aic1IiIuf8a4jSm+HBVqslqT9eozW1h5YR xAZpasfxTgbwncC8GCeKSIPy+wX93VeDFx2txefmj4Jcy+zotNLIKuAJKrplBRrbtFFG VveUTma4locRqvFNNQJFr6mL0gp50vPFtdJg6wJ9XJdDtFHpqqVB9ecYO/bnIsNYadr2 qoV6e9BGIzuDwM/Hew5+b0i1SUndmPkKoa2Saa71Rd6Vx/gFufPdY7DVnB3AImWlE5rH BRJA== X-Gm-Message-State: AAQBX9emheE9wVgUT7dbo1wKnvWLUYpepE112ZrHFGeDoy+VJdNWf8/l /ZUPvI5ietIToUTKRUke0+olXA== X-Received: by 2002:a05:622a:1181:b0:3e3:90f7:b33c with SMTP id m1-20020a05622a118100b003e390f7b33cmr5002528qtk.7.1679670894617; Fri, 24 Mar 2023 08:14:54 -0700 (PDT) Received: from nicolas-tpx395.localdomain (192-222-136-102.qc.cable.ebox.net. [192.222.136.102]) by smtp.gmail.com with ESMTPSA id n14-20020ac8674e000000b003d65e257f10sm4230146qtp.79.2023.03.24.08.14.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 08:14:54 -0700 (PDT) Message-ID: <2d6480e36ce061a63440d1e11d52b02e57ba746d.camel@ndufresne.ca> Subject: Re: [RFC 2/4] media: videobuf2: Replace bufs array by a list From: Nicolas Dufresne To: Laurent Pinchart 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" Date: Fri, 24 Mar 2023 11:14:52 -0400 In-Reply-To: <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> <20230322150153.GO20234@pendragon.ideasonboard.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE 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 Le mercredi 22 mars 2023 =C3=A0 17:01 +0200, Laurent Pinchart a =C3=A9crit= =C2=A0: > On Wed, Mar 22, 2023 at 10:50:52AM -0400, Nicolas Dufresne wrote: > > Hi Laurent, > >=20 > > Le lundi 20 mars 2023 =C3=A0 01:33 +0200, Laurent Pinchart a =C3=A9crit= =C2=A0: > > > > The typical usage is that applications allocate N buffers with the > > > > VIDIOC_REQBUFS ioctl, and in most cases that's all they use. > > >=20 > > > 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). > >=20 > > I was wondering if you can extend on this. I'm worried the count semant= ic 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() ? >=20 > For drivers it should be fairly simply, as the reqbufs and create_bufs > ioctl handlers should just point to the corresponding videobuf2 helpers. >=20 > What I meant is that I'd like to encourage userspace to use the > VIDIOC_CREATE_BUFS ioctl instead of VIDIOC_REQBUFS. >=20 I'm not sure what rationale I can give implementer to "encourage" them to u= se a more complex API that needs to copy over the FMT (which has just been set), specially in the initial pre-allocation case. For most, CREATE_BUFS after S= MT will look like a very redundant and counter intuitive thing. Maybe you have= a more optimistic view on the matter ? Or you have a better idea how we could= give a meaning to having a fmt there on the initial case where the allocation ma= tches the queue FMT ? Nicolas