All of lore.kernel.org
 help / color / mirror / Atom feed
From: niklas soderlund <niklas.soderlund@ragnatech.se>
To: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>,
	Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH v6 7/7] media: vsp1: pipe: Add RAW Bayer formats mapping
Date: Mon, 24 Mar 2025 09:35:13 +0100	[thread overview]
Message-ID: <20250324083513.GA2884853@ragnatech.se> (raw)
In-Reply-To: <dkatmlnysvsy3g4n3m53bzxcqx4avklzfctxgjv4hl6sd7fte3@vlfsvasn53d7>

Hello Jacopo,

On 2025-03-24 09:27:56 +0100, Jacopo Mondi wrote:
> 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@ragnatech.se>
> > > Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> > > Signed-off-by: Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
> > > ---
> > > 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 ?

I would rather keep the true formats in the API between the VSP and ISP, 
that is keep it as is. If really needed maybe a translation in the VSP 
driver prior to querying vsp1_video_formats[] could be added? But this 
driver is complex enough as-is :-)

> 
> 
> >
> > 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

-- 
Kind Regards,
Niklas Söderlund

  reply	other threads:[~2025-03-24  8:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 15:45 [PATCH v6 0/7] media: renesas: vsp1: Add support for IIF Jacopo Mondi
2025-03-21 15:45 ` [PATCH v6 1/7] media: vsp1: Add support IIF ISP Interface Jacopo Mondi
2025-03-21 15:45 ` [PATCH v6 2/7] media: vsp1: dl: Use singleshot DL for VSPX Jacopo Mondi
2025-03-21 15:45 ` [PATCH v6 3/7] media: vsp1: rwpf: Break out format handling Jacopo Mondi
2025-03-21 15:45 ` [PATCH v6 4/7] media: vsp1: wpf: Propagate vsp1_rwpf_init_ctrls() Jacopo Mondi
2025-03-21 15:45 ` [PATCH v6 5/7] media: vsp1: rwpf: Initialize image formats Jacopo Mondi
2025-03-21 17:08   ` Laurent Pinchart
2025-03-21 15:45 ` [PATCH v6 6/7] media: vsp1: rwpf: Support operations with IIF Jacopo Mondi
2025-03-21 15:45 ` [PATCH v6 7/7] media: vsp1: pipe: Add RAW Bayer formats mapping Jacopo Mondi
2025-03-21 21:56   ` Laurent Pinchart
2025-03-24  8:27     ` Jacopo Mondi
2025-03-24  8:35       ` niklas soderlund [this message]
2025-03-24 15:51         ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250324083513.GA2884853@ragnatech.se \
    --to=niklas.soderlund@ragnatech.se \
    --cc=jacopo.mondi+renesas@ideasonboard.com \
    --cc=jacopo.mondi@ideasonboard.com \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.