Re: [PATCH v6 7/7] media: vsp1: pipe: Add RAW Bayer formats mapping

From: Jacopo Mondi
Date: Mon Mar 24 2025 - 04:28:11 EST

Next message: Baochen Qiang: "Re: [PATCH] wifi: ath12k: extend dma mask to 36 bits"
Previous message: Ingo Molnar: "Re: [PATCH] x86/kbuild/64: Test for the availability of the -mtune=native compiler flag"
Next in thread: niklas soderlund: "Re: [PATCH v6 7/7] media: vsp1: pipe: Add RAW Bayer formats mapping"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hi Laurent

On Fri, Mar 21, 2025 at 11:56:34PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Fri, Mar 21, 2025 at 04:45:39PM +0100, Jacopo Mondi wrote:
> > Add formats definition for RAW Bayer formats in vsp1_pipe.c.
> >
> > 8-bits RAW Bayer pixel formats map on VSP format RGB332.
>
> s/map on/map to/
>
> > 10, 12 and 16 bits RAW Bayer pixel formats map on RGB565 insted.
> >
> > Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> > Tested-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> > Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@xxxxxxxxxxxxxxxx>
> > ---
> > v3->v4:
> > - Fix SWAP bits for RAW 10, 12 and 16
> > ---
> > drivers/media/platform/renesas/vsp1/vsp1_pipe.c | 72 ++++++++++++++++++++++++-
> > 1 file changed, 71 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> > index 8e9be3ec1b4d..a51061738edc 100644
> > --- a/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> > +++ b/drivers/media/platform/renesas/vsp1/vsp1_pipe.c
> > @@ -30,10 +30,80 @@
> > */
> >
> > static const struct vsp1_format_info vsp1_video_formats[] = {
> > - { V4L2_PIX_FMT_RGB332, MEDIA_BUS_FMT_ARGB8888_1X32,
> > + /* Raw Bayer 8-bit: Maps on RGB332 */
> > + { V4L2_PIX_FMT_SBGGR8, MEDIA_BUS_FMT_Y8_1X8,
> > + VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> > + 1, { 8, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGBRG8, MEDIA_BUS_FMT_Y8_1X8,
> > + VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> > + 1, { 8, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGRBG8, MEDIA_BUS_FMT_Y8_1X8,
> > + VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> > + 1, { 8, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SRGGB8, MEDIA_BUS_FMT_Y8_1X8,
> > VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> > 1, { 8, 0, 0 }, false, false, 1, 1, false },
>
> Similarly to the media bus codes, could we have a single entry, using
> V4L2_PIX_FMT_GREY ? Same below with V4L2_PIX_FMT_Y10, V4L2_PIX_FMT_Y12
> and V4L2_PIX_FMT_Y16.

mmm, the SRGB mbus codes come from the R-Car ISP input image format.
I understand these are multiple identical entries, but having
somewhere a translation from SRGB->Y formats just to have fewer
entries here it feels a bit of an hack

>
> This would still duplicate entries, as V4L2_PIX_FMT_Y1[026] are
> essentially treated the same, and they are identical to
> V4L2_PIX_FMT_RGB565. We could ask the ISP driver to use
> V4L2_PIX_FMT_RGB565 (and V4L2_PIX_FMT_RGB332 for 8-bit raw) when
> configuring the VSPX, but that's a bit of a hack.

Indeed, but I don't think 3 "duplicated" entries are any bad, if
that's how the HW work.

>
> Another option would be to handle the translation in
> vsp1_vspx_rwpf_set_subdev_fmt(). I would still in that case only expect
> the V4L2_PIX_FMT_GREY and V4L2_PIX_FMT_Y* 4CCs from the ISP driver. This

Do you expect the ISP driver to translate SRGB to Y formats ?

> patch could then be dropped.

So are you suggesting to translate in the ISP driver

SRGB8 -> RGB332

SRGB10/12/16 -> RGB565

Niklas, what do you think ?

>
> What's your preference ?
>
> > +
> > + /* Raw Bayer 10/12/16-bit: Maps on RGB565 */
> > + { V4L2_PIX_FMT_SBGGR10, MEDIA_BUS_FMT_Y10_1X10,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 10, 0, 0 }, false, false, 1, 1, false },
>
> The bpp values are used to calculate memory offsets. Unless I'm
> mistaken, you should use 16 here, not 10.
>

I'm rounding up in the vspx driver. However it is true these formats
are sampled in 16bpp chunks, so I can use 16 here.

> > + { V4L2_PIX_FMT_SGBRG10, MEDIA_BUS_FMT_Y10_1X10,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 10, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGRBG10, MEDIA_BUS_FMT_Y10_1X10,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 10, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SRGGB10, MEDIA_BUS_FMT_Y10_1X10,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 10, 0, 0 }, false, false, 1, 1, false },
> > +
> > + { V4L2_PIX_FMT_SBGGR12, MEDIA_BUS_FMT_Y12_1X12,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 12, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGBRG12, MEDIA_BUS_FMT_Y12_1X12,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 12, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGRBG12, MEDIA_BUS_FMT_Y12_1X12,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 12, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SRGGB12, MEDIA_BUS_FMT_Y12_1X12,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 12, 0, 0 }, false, false, 1, 1, false },
> > +
> > + { V4L2_PIX_FMT_SBGGR16, MEDIA_BUS_FMT_Y16_1X16,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 16, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGBRG16, MEDIA_BUS_FMT_Y16_1X16,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 16, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SGRBG16, MEDIA_BUS_FMT_Y16_1X16,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 16, 0, 0 }, false, false, 1, 1, false },
> > + { V4L2_PIX_FMT_SRGGB16, MEDIA_BUS_FMT_Y16_1X16,
> > + VI6_FMT_RGB_565, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS,
> > + 1, { 16, 0, 0 }, false, false, 1, 1, false },
> > +
> > + { V4L2_PIX_FMT_RGB332, MEDIA_BUS_FMT_ARGB8888_1X32,
> > + VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > + VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> > + 1, { 10, 0, 0 }, false, false, 1, 1, false },
>
> This doesn't seem right, the patch is changing the V4L2_PIX_FMT_RGB332.

If I'm not mistaken V4L2_PIX_FMT_RGB332 was

{ V4L2_PIX_FMT_RGB332, MEDIA_BUS_FMT_ARGB8888_1X32,
VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
1, { 8, 0, 0 }, false, false, 1, 1, false }

and is now

{ V4L2_PIX_FMT_RGB332, MEDIA_BUS_FMT_ARGB8888_1X32,
VI6_FMT_RGB_332, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
1, { 10, 0, 0 }, false, false, 1, 1, false },

Seems like I messed up the bpp

With that fixed the diff looks saner. Thanks for spotting.

>
> > { V4L2_PIX_FMT_ARGB444, MEDIA_BUS_FMT_ARGB8888_1X32,
> > VI6_FMT_ARGB_4444, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> > VI6_RPF_DSWAP_P_WDS,
>
> --
> Regards,
>
> Laurent Pinchart

Next message: Baochen Qiang: "Re: [PATCH] wifi: ath12k: extend dma mask to 36 bits"
Previous message: Ingo Molnar: "Re: [PATCH] x86/kbuild/64: Test for the availability of the -mtune=native compiler flag"
Next in thread: niklas soderlund: "Re: [PATCH v6 7/7] media: vsp1: pipe: Add RAW Bayer formats mapping"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]