Re: [PATCH v5 1/6] media: v4l2: Add Renesas Camera Receiver Unit pixel formats

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Jun 24, 2025 at 09:35:04PM +0000, Sakari Ailus wrote:
> On Tue, Jun 24, 2025 at 06:20:33PM +0300, Laurent Pinchart wrote:
> > On Tue, Jun 24, 2025 at 10:25:19AM +0000, Sakari Ailus wrote:
> > > On Mon, Jun 23, 2025 at 03:43:18PM +0100, Daniel Scally wrote:
> > > > From: Daniel Scally <dan.scally+renesas@ideasonboard.com>
> > > > 
> > > > The Renesas Camera Receiver Unit in the RZ/V2H SoC can output RAW
> > > > data captured from an image sensor without conversion to an RGB/YUV
> > > > format. In that case the data are packed into 64-bit blocks, with a
> > > > variable amount of padding in the most significant bits depending on
> > > > the bitdepth of the data. Add new V4L2 pixel format codes for the new
> > > > formats, along with documentation to describe them.
> > > > 
> > > > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > > Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > > Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
> > > > Signed-off-by: Daniel Scally <dan.scally+renesas@ideasonboard.com>
> > > > ---
> > > > Changes in v5:
> > > > 
> > > > 	- None
> > > > 
> > > > Changes in v4:
> > > > 
> > > > 	- Removed references to "Bayer" or "srgb"
> > > > 
> > > > Changes in v3:
> > > > 
> > > > 	- Switched from bayer-order specific formats to generic RAWnn
> > > > 
> > > > Changes in v2:
> > > > 
> > > > 	- Added labels to the new formats in the documentation file
> > > > 	- Added 20-bit formats
> > > > ---
> > > >  .../userspace-api/media/v4l/pixfmt-bayer.rst       |   1 +
> > > >  .../userspace-api/media/v4l/pixfmt-rawnn-cru.rst   | 143 +++++++++++++++++++++
> > > >  drivers/media/v4l2-core/v4l2-common.c              |   6 +
> > > >  drivers/media/v4l2-core/v4l2-ioctl.c               |   4 +
> > > >  include/uapi/linux/videodev2.h                     |   6 +
> > > >  5 files changed, 160 insertions(+)
> > > > 
> > > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-bayer.rst b/Documentation/userspace-api/media/v4l/pixfmt-bayer.rst
> > > > index ed3eb432967d9845d3d65150831d8a7f62dec994..20a8aa04330479ed4d44c8e4fc3d57db8c2e6933 100644
> > > > --- a/Documentation/userspace-api/media/v4l/pixfmt-bayer.rst
> > > > +++ b/Documentation/userspace-api/media/v4l/pixfmt-bayer.rst
> > > > @@ -31,3 +31,4 @@ orders. See also `the Wikipedia article on Bayer filter
> > > >      pixfmt-srggb14
> > > >      pixfmt-srggb14p
> > > >      pixfmt-srggb16
> > > > +    pixfmt-rawnn-cru
> > > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rawnn-cru.rst b/Documentation/userspace-api/media/v4l/pixfmt-rawnn-cru.rst
> > > > new file mode 100644
> > > > index 0000000000000000000000000000000000000000..d786833d0cf355b3955fe63d85c8a211a7a4fb23
> > > > --- /dev/null
> > > > +++ b/Documentation/userspace-api/media/v4l/pixfmt-rawnn-cru.rst
> > > > @@ -0,0 +1,143 @@
> > > > +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
> > > > +
> > > > +.. _v4l2-pix-fmt-cru-raw10:
> > > > +.. _v4l2-pix-fmt-cru-raw12:
> > > > +.. _v4l2-pix-fmt-cru-raw14:
> > > > +.. _v4l2-pix-fmt-cru-raw20:
> > > > +
> > > > +**********************************************************************************************************************************
> > > > +V4L2_PIX_FMT_CRU_RAW10 ('CR10'), V4L2_PIX_FMT_CRU_RAW12 ('CR12'), V4L2_PIX_FMT_CRU_RAW14 ('CR14'), V4L2_PIX_FMT_CRU_RAW20 ('CR20')
> > > > +**********************************************************************************************************************************
> > > 
> > > Regarding naming, could these be called V4L2_PIX_FMT_RAW_CRUxx, to align
> > > the naming with the new raw formats?
> > > <URL:https://www.retiisi.eu/~sailus/v4l2/tmp/common-raw/userspace-api/media/v4l/pixfmt-raw-generic.html>
> > > 
> > > If you rebase on the metadata series, I can pick this patch in the set. My
> > > objective is to get this merged in this cycle, which of course also depends
> > > on review feedback.
> > 
> > Your set is big enough :-)
> > 
> > Unless I'm missing something, this patch doesn't depend on the metadata
> > series. I plan to pick up Dan's next version (with the formats renamed)
> > and send a pull request.
> 
> That works, too. I believe people are generally happy with the approach of
> conveying the color pattern. But you still need the metadata series for
> these to work I suppose?

Not with this patch series, as far as I can tell.

> Do you btw. intend to use these in conjunction with the usual Bayer mbus
> codes? It might be useful to have helpers for this purpose but we could add
> them later on (and probably not just for that).

See patch 6/6, the regularo bayer media bus codes are used with these
pixel formats.

Ideally I'd ditch the bayer media bus codes and use the raw media bus
codes, but those are not in mainline yet. It would add a dependency on
the metadata series.

-- 
Regards,

Laurent Pinchart