mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: "Sven Püschel" <s.pueschel@pengutronix.de>,
	"Jacob Chen" <jacob-chen@iotwrt.com>,
	"Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Hans Verkuil" <hverkuil+cisco@kernel.org>
Cc: linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,  kernel@pengutronix.de,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Michael Tretter	 <m.tretter@pengutronix.de>
Subject: Re: [PATCH] media: rockchip: rga: don't change RGB quantization
Date: Wed, 15 Jul 2026 20:57:06 -0400	[thread overview]
Message-ID: <0c1c07cbdcbb3a6852e2fc13b94b84d7641f5b6d.camel@collabora.com> (raw)
In-Reply-To: <20260605-spu-fixrga3quantization-v1-1-1059d984dc6e@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]

Le vendredi 05 juin 2026 à 15:32 +0200, Sven Püschel a écrit :
> Don't change the quantization of an RGB format when converting between
> RGB and YUV with the RGA3. As the RGA3 only supports doing conversions
> to full range YUV with BT601, it wants to announce it through
> try_fmt/s_fmt.
> 
> As it is only relevant, when converting between RGB and YUV, it's
> guarded by a given condition. But the condition also causes the
> RGB format quantization to be adjusted to limited range, which
> is incorrect.
> 
> Therefore simplify the condition to only apply when the current format
> is a YUV format. Also document the reason for checking if the other
> format is an RGB format.
> 
> Fixes: 24a63d4c9d3c ("media: rockchip: rga: add rga3 support")
> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>

Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>

> ---
> This patch is a fix to the upcoming RGA3 support. By mistake it'll also
> adjust the RGB quantization instead of only adjusting the quantization
> of the YUV formats. Therefore remove the incorrect conditions and
> document why we also check the format of the other side.
> 
> I've just noticed this flawed condition and didn't check/reproduce it in
> a practical scenario.
> 
>     v4l2-compliance 1.32.0, 64 bits, 64-bit time_t
>     ....
>     	Card type        : rga3
>     ...
>     Total for rockchip-rga device /dev/video0: 48, Succeeded: 48, Failed: 0, Warnings: 0
> 
>     v4l2-compliance 1.32.0, 64 bits, 64-bit time_t
>     ...
>     	Card type        : rga2
>     ...
>     Total for rockchip-rga device /dev/video1: 48, Succeeded: 48, Failed: 0, Warnings: 0
> ---
>  drivers/media/platform/rockchip/rga/rga3-hw.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/rockchip/rga/rga3-hw.c b/drivers/media/platform/rockchip/rga/rga3-hw.c
> index ca1c268303dd4..c4a71306278ba 100644
> --- a/drivers/media/platform/rockchip/rga/rga3-hw.c
> +++ b/drivers/media/platform/rockchip/rga/rga3-hw.c
> @@ -450,10 +450,14 @@ static void *rga3_adjust_and_map_format(struct rga_ctx *ctx,
>  	other_format = is_output ? &ctx->out.pix : &ctx->in.pix;
>  	other_format_info = v4l2_format_info(other_format->pixelformat);
>  
> -	if ((v4l2_is_format_rgb(format_info) &&
> -	     v4l2_is_format_yuv(other_format_info)) ||
> -	    (v4l2_is_format_yuv(format_info) &&
> -	     v4l2_is_format_rgb(other_format_info))) {
> +	/*
> +	 * Only apply the quantization restrictions when we need to
> +	 * convert between RGB and YUV. Otherwise there is no point
> +	 * to limit the quantization for operations like scaling or
> +	 * rotations.
> +	 */
> +	if (v4l2_is_format_yuv(format_info) &&
> +	    v4l2_is_format_rgb(other_format_info)) {
>  		/*
>  		 * The RGA3 only supports BT601, BT709 and BT2020 RGB<->YUV conversions
>  		 * Additionally BT709 and BT2020 only support limited range YUV.
> 
> ---
> base-commit: 6a75e3d4f6428b90f398354212e3a2e0172851d6
> change-id: 20260605-spu-fixrga3quantization-061c761a1d80
> 
> Best regards,
> --  
> Sven Püschel <s.pueschel@pengutronix.de>
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2026-07-16  0:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-05 13:32 Sven Püschel
2026-07-16  0:57 ` Nicolas Dufresne [this message]

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=0c1c07cbdcbb3a6852e2fc13b94b84d7641f5b6d.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=heiko@sntech.de \
    --cc=hverkuil+cisco@kernel.org \
    --cc=jacob-chen@iotwrt.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=m.tretter@pengutronix.de \
    --cc=mchehab@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=s.pueschel@pengutronix.de \
    /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

all inboxes | Powered by JetHome®