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;
Message-ID: <df2a19b7fd0238808f00973b2cb5f4f478c38ef9.camel@ndufresne.ca>
Subject: Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify
 single/multi-planar handling (and more)
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Tomasz Figa <tfiga@chromium.org>,
        Hsia-Jun Li <Randy.Li@synaptics.com>
Cc:     mchehab@kernel.org, hans.verkuil@cisco.com,
        laurent.pinchart@ideasonboard.com, sakari.ailus@iki.fi,
        boris.brezillon@collabora.com, hiroh@chromium.org,
        Brian.Starkey@arm.com, kernel@collabora.com,
        narmstrong@baylibre.com, linux-kernel@vger.kernel.org,
        frkoenig@chromium.org, stanimir.varbanov@linaro.org,
        Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Date:   Tue, 15 Nov 2022 11:03:26 -0500
In-Reply-To: <CAAFQd5DD4QgDs-Dff_SB2tNT3d9Hs8HG0rkQFPV+6vgvKqg+qA@mail.gmail.com>
References: <20210114180738.1758707-1-helen.koike@collabora.com>
         <20210114180738.1758707-3-helen.koike@collabora.com>
         <d0d1f74f-7e77-1b18-0529-dbbec8889584@xs4all.nl>
         <577c56bf-146c-f34a-2028-075170076de7@collabora.com>
         <708221e8-a805-c394-6958-6c7ec24bfe66@synaptics.com>
         <03f6fd9ff6a757f6d1cb6cc552efcb0b94327104.camel@ndufresne.ca>
         <3b1edf81-bcc0-0b56-7e55-93da55d7f747@synaptics.com>
         <CAAFQd5Ab0giyCS_69Wt4=C9yiBmLfV=0yZY2vGeaOwFgGsb_bQ@mail.gmail.com>
         <91a96b4a-a91e-aae6-733f-c307ca6840f0@synaptics.com>
         <CAAFQd5DD4QgDs-Dff_SB2tNT3d9Hs8HG0rkQFPV+6vgvKqg+qA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) 
MIME-Version: 1.0
Precedence: bulk

Le vendredi 11 novembre 2022 =C3=A0 17:52 +0900, Tomasz Figa a =C3=A9crit=
=C2=A0:
> > > Memory allocation doesn't sound to me like it is related to formats o=
r
> > > modifiers in any way. I agree with Nicolas that if we want to allow
> > > the userspace to specify if the memory should be contiguous or not,
> > > that should be a separate flag and actually I'd probably see it in
> > > REQBUF_EXT and CREATE_BUFS_EXT, rather than as a part of the format.
> > >=20
> > I agree with that. But here is a problem, if there was a display
> > device(DRM) that only supports contiguous planes in a frame buffer.
> > How do we be aware of that?
>=20
> That's why I think the MMAP mode is not scalable and shouldn't be
> expanded anymore. Both V4L2 and DRM devices should describe their
> constraints to the userspace and then the userspace should allocate
> accordingly from the right DMA-buf heap. (Or as Android and ChromeOS
> do, just have a central allocator library that understands the
> constraints, so there is no need to query the drivers.)

Just pointing out, they "hardcode" the constraints, they don't truly unders=
tand
them. Also, the Android/ChromeOS implementation is not a great playground, =
as it
completely ignores the constrait already exposed by V4L2 API (the sizeimage=
 and
bytesperline found in the FMT structure). You would not have to implement H=
antro
and Rockchip motion vector size calculation there if you'd simply use the
sizeimage.

Nicolas