Linux Media Controller development
 help / color / mirror / Atom feed
From: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
To: "Niklas Söderlund" <niklas.soderlund+renesas@ragnatech.se>
Cc: Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
	 Jai Luthra <jai.luthra+renesas@ideasonboard.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	 linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	 Jacopo Mondi <jacopo.mondi+renesas@ideasonboard.com>
Subject: Re: [PATCH v9 03/13] media: rppx1: Add framework to support Dreamchip RPPX1 ISP
Date: Wed, 3 Jun 2026 17:33:50 +0200	[thread overview]
Message-ID: <aiBHR2A5WqNfcmv_@zed> (raw)
In-Reply-To: <20260603151715.GF91369@ragnatech.se>

Hi Niklas

On Wed, Jun 03, 2026 at 05:17:15PM +0200, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your feedback.
>
> On 2026-06-03 16:26:45 +0200, Jacopo Mondi wrote:
>
> [ snip ]
>
> > > > > diff --git a/drivers/media/platform/dreamchip/rppx1/rppx1_ccor.c
> > > > > b/drivers/media/platform/dreamchip/rppx1/rppx1_ccor.c
> > > > > new file mode 100644
> > > > > index 000000000000..3bfad3ba12e6
> > > > > --- /dev/null
> > > > > +++ b/drivers/media/platform/dreamchip/rppx1/rppx1_ccor.c
> > > > > @@ -0,0 +1,105 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +/*
> > > > > + * Copyright (C) 2026 Renesas Electronics Corp.
> > > > > + * Copyright (C) 2026 Ideas on Board Oy
> > > > > + * Copyright (C) 2026 Ragnatech AB
> > > > > + */
> > > > > +
> > > > > +#include "rpp_module.h"
> > > > > +
> > > > > +#define CCOR_VERSION_REG				0x0000
> > > > > +
> > > > > +#define CCOR_COEFF_REG_NUM				9
> > > > > +#define CCOR_COEFF_REG(n)				(0x0004 + (4 * (n)))
> > > > > +
> > > > > +#define CCOR_OFFSET_R_REG				0x0028
> > > > > +#define CCOR_OFFSET_G_REG				0x002c
> > > > > +#define CCOR_OFFSET_B_REG				0x0030
> > > > > +
> > > > > +#define CCOR_CONFIG_TYPE_REG				0x0034
> > > > > +#define CCOR_CONFIG_TYPE_USE_OFFSETS_AS_PRE_OFFSETS	BIT(1)
> > > > > +#define CCOR_CONFIG_TYPE_CCOR_RANGE_AVAILABLE		BIT(0)
> > > > > +
> > > > > +#define CCOR_RANGE_REG					0x0038
> > > > > +#define CCOR_RANGE_CCOR_C_RANGE				BIT(1)
> > > > > +#define CCOR_RANGE_CCOR_Y_RANGE				BIT(0)
> > > > > +
> > > > > +static int rppx1_ccor_probe(struct rpp_module *mod)
> > > > > +{
> > > > > +	/* Version check. */
> > > > > +	switch (rpp_module_read(mod, CCOR_VERSION_REG)) {
> > > > > +	case 3:
> > > > > +		/* 12-bit. */
> > > > > +		break;
> > > > > +	case 4:
> > > > > +		/* 20-bit. */
> > > > > +		break;
> > > > > +	case 5:
> > > > > +		/* 24-bit. */
> > > > > +		break;
> > > > > +	default:
> > > > > +		return -EINVAL;
> > > > > +	}
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > > +static int rppx1_ccor_start(struct rpp_module *mod,
> > > > > +			    const struct v4l2_mbus_framefmt *fmt)
> > > > > +{
> > > > > +	/* Configure matrix in bypass mode. */
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(0), 0x1000);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(1), 0x0000);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(2), 0x0000);
> > > > > +
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(3), 0x0000);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(4), 0x1000);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(5), 0x0000);
> > > > > +
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(6), 0x0000);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(7), 0x0000);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(8), 0x1000);
> > > > > +
> > > > > +	rpp_module_write(mod, CCOR_OFFSET_R_REG, 0x00000000);
> > > > > +	rpp_module_write(mod, CCOR_OFFSET_G_REG, 0x00000000);
> > > > > +	rpp_module_write(mod, CCOR_OFFSET_B_REG, 0x00000000);
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > > +const struct rpp_module_ops rppx1_ccor_ops = {
> > > > > +	.probe = rppx1_ccor_probe,
> > > > > +	.start = rppx1_ccor_start,
> > > > > +};
> > > > > +
> > > > > +static int rppx1_ccor_csm_start(struct rpp_module *mod,
> > > > > +				const struct v4l2_mbus_framefmt *fmt)
> > > > > +{
> > > > > +	/* Reuse bypass matrix setup. */
> > > > > +	if (fmt->code == MEDIA_BUS_FMT_RGB888_1X24)
> > > > > +		return rppx1_ccor_start(mod, fmt);
> > > > > +
> > > > > +	/* Color Transformation RGB to YUV according to ITU-R BT.709. */
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(0), 0x0367);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(1), 0x0b71);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(2), 0x0128);
> > > > > +
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(3), 0xfe2b);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(4), 0xf9d5);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(5), 0x0800);
> > > > > +
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(6), 0x0800);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(7), 0xf8bc);
> > > > > +	rpp_module_write(mod, CCOR_COEFF_REG(8), 0xff44);
> > > > > +
> > > > > +	rpp_module_write(mod, CCOR_OFFSET_R_REG, 0x00000000);
> > > > > +	rpp_module_write(mod, CCOR_OFFSET_G_REG, 0x00000800);
> > > > > +	rpp_module_write(mod, CCOR_OFFSET_B_REG, 0x00000800);
> > > >
> > > > Is this a leftover or is it intetional ?
> > >
> > > Intentional.
> > >
> > > Most of the _start callbacks just disables or configure pass-thru mode
> > > of each modules that are not used (read not yet configured by
> > > user-space). And this is what is done here, configure the CCOR in
> > > pass-thru mode.
> > >
> > > The RGB case is easiest as it's just configure the identity matrix.
> > > While for the YUV case we need to pick something as a default and I
> > > picked ITU-R BT.709 as IIRC this was the default for RkISP1.
> >
> > Sorry, I don't think I'm following here.
> >
> > Color correction is applied in RGB space, what's the YUV case and
> > why should you use the CCM for color-space conversion ?
> >
> > Are you confusing this block with the colorspace conversion matrix in
> > the AWB stats engine that is used to return stats in YUV mode ?
>
> I thought I had it clear in my mind, but after reading this I'm confused
> too ;-) Let's start from scratch and hash this out.
>
> In rppx1_ccor.c there is code for a color correction module. A bit
> simplified this module is a color matrix multiplication and an offset
> for each color component. However this module is used in three
> different places,
>
> - In the POST pipeline as the CCOR module used for color correction
>   control. See CCOR_BASE in datasheet. In this driver this module is
>   implemented as struct rpp_module_ops rppx1_ccor_ops.
>
> - In each of the two OUTPUT pipelines (Human Vision and Machine Vision)
>   as a CSM color space matrix where it is used for conversion from
>   linear RGB to YcbCr. See CSM_BASE in the datasheet. In this driver
>   this module is implemented as struct rpp_module_ops
>   rppx1_ccor_csm_ops.

I had completely missed this is the 'csm' and this module handles both
the CCM and the color space conversion o_0

I thought only CCM was handled here.

>
> Both struct rppx1_ccor_ops and struct rppx1_ccor_csm_ops are implemented
> in this rppx1_ccor.c file as they module is the same only the
> configuration of them differ as they have different functions in the
> pipeline.
>

Oook I was not expecting this


> For the CCOR module in the POST pipeline it can be used to correct
> colors. As we have no disable bit for this module we configure it in
> pass-thru mode in rppx1_ccor_start() by just programming the identity
> matrix and no offsets.
>
> For the CSM module in each of the two OUTPUT pipelines (only Human
> Vision is supported) the function is to do color space conversion. And
> this is what we see here in rppx1_ccor_csm_start().
>
> If the output format of the RPPX1 is to be RGB we do "nothing" and just
> program the identity matrix with no offsets by calling
> rppx1_ccor_start(). However if the output format is to be YUYV we need
> convert it, and that is what you see here. IIRC I picked RGB to YUV
> according to ITU-R BT.709 as this is what RkISP1 do.
>
> Without this we are not able to support both output formats. So for SCM
> this can't really be configured at runtime as it depends on the output
> format. While for CCOR it can be configured at runtime but we need some
> default setting to start with, else I have seen either complete black
> images or a lockup of the pipeline.
>
> Does it make sens? It is a tad confusing as the same code is used for
> different functions at different stages in the pipeline.
>

I completely missed the 'csm' part. I guess this is ok, even in a
single file.

Sorry for the noise and thanks for the time taken.

> >
> > >
> > > >
> > > > Userspace is expected to fully configure the block, I'm not sure this
> > > > default initialization is useful.
> > >
> > > If this is not configured I have been able to lockup the whole
> > > processing pipeline during development.
> > >
> >
> > Indeed, if there's no disable bit, the ccm shall be programmed with an
> > identity matrix
> >
> >  write(priv, mod->base + CCOR_COEFF_REG(0), 0x1000);
> >  write(priv, mod->base + CCOR_COEFF_REG(1), 0x0000);
> >  write(priv, mod->base + CCOR_COEFF_REG(2), 0x0000);
> >
> >  write(priv, mod->base + CCOR_COEFF_REG(3), 0x0000);
> >  write(priv, mod->base + CCOR_COEFF_REG(4), 0x1000);
> >  write(priv, mod->base + CCOR_COEFF_REG(5), 0x0000);
> >
> >  write(priv, mod->base + CCOR_COEFF_REG(6), 0x0000);
> >  write(priv, mod->base + CCOR_COEFF_REG(7), 0x0000);
> >  write(priv, mod->base + CCOR_COEFF_REG(8), 0x1000);
> >
> >  write(priv, mod->base + CCOR_OFFSET_R_REG, 0x00000000);
> >  write(priv, mod->base + CCOR_OFFSET_G_REG, 0x00000000);
> >  write(priv, mod->base + CCOR_OFFSET_B_REG, 0x00000000);
> >
> > ?
>
> Yes and that is what we do in CCOR module (always) and in CSM if output
> is RGB.
>
> >
> > > >
> > > > > +
> > > > > +	return 0;
> > > > > +}
> > > > > +
> > > > > +const struct rpp_module_ops rppx1_ccor_csm_ops = {
> > > > > +	.probe = rppx1_ccor_probe,
> > > > > +	.start = rppx1_ccor_csm_start,
> > > > > +};
> > > > > diff --git a/drivers/media/platform/dreamchip/rppx1/rppx1_db.c b/drivers/media/platform/dreamchip/rppx1/rppx1_db.c
> > > > > new file mode 100644
>
> [snip]
>
> --
> Kind Regards,
> Niklas Söderlund

  reply	other threads:[~2026-06-03 15:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-16 21:13 [PATCH v9 00/13] media: Add support for R-Car ISP using Dreamchip RPPX1 ISP Niklas Söderlund
2026-05-16 21:13 ` [PATCH v9 01/13] media: Add RPP_X1_PARAMS and RPP_X1_STATS meta formats Niklas Söderlund
2026-06-03 10:49   ` Jacopo Mondi
2026-06-03 12:48     ` Niklas Söderlund
2026-05-16 21:13 ` [PATCH v9 02/13] media: uapi: Add extensible param and stats blocks for RPPX1 Niklas Söderlund
2026-06-03 10:50   ` Jacopo Mondi
2026-06-03 12:55     ` Niklas Söderlund
2026-05-16 21:13 ` [PATCH v9 03/13] media: rppx1: Add framework to support Dreamchip RPPX1 ISP Niklas Söderlund
2026-06-03 10:56   ` Jacopo Mondi
2026-06-03 12:24   ` Jacopo Mondi
2026-06-03 13:47     ` Niklas Söderlund
2026-06-03 14:26       ` Jacopo Mondi
2026-06-03 15:17         ` Niklas Söderlund
2026-06-03 15:33           ` Jacopo Mondi [this message]
2026-05-16 21:13 ` [PATCH v9 04/13] media: rcar-isp: Add support for ISPCORE Niklas Söderlund
2026-06-03 13:15   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 05/13] media: rppx1: wbmeas: Add support for white balance measurement Niklas Söderlund
2026-06-03 13:35   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 06/13] media: rppx1: awbg: Add support for white balance gain settings Niklas Söderlund
2026-06-03 13:38   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 07/13] media: rppx1: exm: Add support for exposure measurement Niklas Söderlund
2026-06-03 13:57   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 08/13] media: rppx1: hist: Add support histogram measurement Niklas Söderlund
2026-06-03 14:11   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 09/13] media: rppx1: bls: Add support for black level compensation Niklas Söderlund
2026-05-16 21:13 ` [PATCH v9 10/13] media: rppx1: ccor: Add support for color correction matrix Niklas Söderlund
2026-05-16 21:13 ` [PATCH v9 11/13] media: rppx1: lsc: Add support for lens shade correction Niklas Söderlund
2026-06-03 14:32   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 12/13] media: rppx1: ga: Add support for gamma out correction Niklas Söderlund
2026-06-03 14:33   ` Jacopo Mondi
2026-05-16 21:13 ` [PATCH v9 13/13] media: rppx1: lin: Add support for gamma sensor linearization Niklas Söderlund
2026-06-03 14:36   ` Jacopo Mondi

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=aiBHR2A5WqNfcmv_@zed \
    --to=jacopo.mondi@ideasonboard.com \
    --cc=jacopo.mondi+renesas@ideasonboard.com \
    --cc=jai.luthra+renesas@ideasonboard.com \
    --cc=kuninori.morimoto.gx@renesas.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 \
    --cc=mchehab@kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox