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

[Dan Scally <dan.scally@ideasonboard.com>]

Hi Laurent, Sakari

On 24/06/2025 23:02, Laurent Pinchart wrote:
> 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.
No; I'm not using the metadata series - this works without it.
>
>> 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.
Indeed
> 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.
>