linux-kernel - Re:[PATCH v7 10/22] drm/rockchip: vop2: Fix YUV444 output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7ab32c86.7542.19be4d21f69.Coremail.andyshrk@163.com>
Date: Thu, 22 Jan 2026 16:28:54 +0800 (CST)
From: "Andy Yan" <andyshrk@....com>
To: "Nicolas Frattaroli" <nicolas.frattaroli@...labora.com>
Cc: "Harry Wentland" <harry.wentland@....com>, "Leo Li" <sunpeng.li@....com>,
	"Rodrigo Siqueira" <siqueira@...lia.com>,
	"Alex Deucher" <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	"David Airlie" <airlied@...il.com>,
	"Simona Vetter" <simona@...ll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>,
	"Maxime Ripard" <mripard@...nel.org>,
	"Thomas Zimmermann" <tzimmermann@...e.de>,
	"Andrzej Hajda" <andrzej.hajda@...el.com>,
	"Neil Armstrong" <neil.armstrong@...aro.org>,
	"Robert Foss" <rfoss@...nel.org>,
	"Laurent Pinchart" <Laurent.pinchart@...asonboard.com>,
	"Jonas Karlman" <jonas@...boo.se>,
	"Jernej Skrabec" <jernej.skrabec@...il.com>,
	"Sandy Huang" <hjc@...k-chips.com>,
	Heiko Stübner <heiko@...ech.de>,
	"Andy Yan" <andy.yan@...k-chips.com>,
	"Jani Nikula" <jani.nikula@...ux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@...el.com>,
	"Joonas Lahtinen" <joonas.lahtinen@...ux.intel.com>,
	"Tvrtko Ursulin" <tursulin@...ulin.net>,
	"Dmitry Baryshkov" <lumag@...nel.org>,
	"Sascha Hauer" <s.hauer@...gutronix.de>,
	"Rob Herring" <robh@...nel.org>, "Jonathan Corbet" <corbet@....net>,
	kernel@...labora.com, amd-gfx@...ts.freedesktop.org,
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, intel-gfx@...ts.freedesktop.org,
	intel-xe@...ts.freedesktop.org, linux-doc@...r.kernel.org
Subject: Re:[PATCH v7 10/22] drm/rockchip: vop2: Fix YUV444 output



Hello Nicolas，

At 2026-01-21 22:45:17, "Nicolas Frattaroli" <nicolas.frattaroli@...labora.com> wrote:
>YUV444 (aka YCbCr444) output isn't working quite right on RK3588. The
>resulting image on the display, while identifying itself as YUV444, has
>some components swapped, even after adding the necessary DRM formats to
>the conversion functions.
>
>Judging by downstream, this is because YUV444 also needs an rb swap
>performed in the AFBC case.
>
>Add the DRM formats to the appropriate switch statements, and add a
>function for checking whether an rb swap needs to be performed in the
>AFBC case.
>
>Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
>Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
>---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
>diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>index ec3b4fde10db..469c63dd97d5 100644
>--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>@@ -176,6 +176,7 @@ static enum vop2_data_format vop2_convert_format(u32 format)
> 	case DRM_FORMAT_ARGB2101010:
> 	case DRM_FORMAT_XBGR2101010:
> 	case DRM_FORMAT_ABGR2101010:
>+	case DRM_FORMAT_VUY101010:
> 		return VOP2_FMT_XRGB101010;
> 	case DRM_FORMAT_XRGB8888:
> 	case DRM_FORMAT_ARGB8888:
>@@ -184,6 +185,7 @@ static enum vop2_data_format vop2_convert_format(u32 format)
> 		return VOP2_FMT_ARGB8888;
> 	case DRM_FORMAT_RGB888:
> 	case DRM_FORMAT_BGR888:
>+	case DRM_FORMAT_VUY888:
> 		return VOP2_FMT_RGB888;
> 	case DRM_FORMAT_RGB565:
> 	case DRM_FORMAT_BGR565:
>@@ -225,6 +227,7 @@ static enum vop2_afbc_format vop2_convert_afbc_format(u32 format)
> 	case DRM_FORMAT_ARGB2101010:
> 	case DRM_FORMAT_XBGR2101010:
> 	case DRM_FORMAT_ABGR2101010:
>+	case DRM_FORMAT_VUY101010:
> 		return VOP2_AFBC_FMT_ARGB2101010;
> 	case DRM_FORMAT_XRGB8888:
> 	case DRM_FORMAT_ARGB8888:
>@@ -233,6 +236,7 @@ static enum vop2_afbc_format vop2_convert_afbc_format(u32 format)
> 		return VOP2_AFBC_FMT_ARGB8888;
> 	case DRM_FORMAT_RGB888:
> 	case DRM_FORMAT_BGR888:
>+	case DRM_FORMAT_VUY888:

How did you test this format? It seems tools like modetest don’t support testing this pattern.



> 		return VOP2_AFBC_FMT_RGB888;
> 	case DRM_FORMAT_RGB565:
> 	case DRM_FORMAT_BGR565:
>@@ -270,6 +274,19 @@ static bool vop2_win_rb_swap(u32 format)
> 	}
> }
> 
>+static bool vop2_afbc_rb_swap(u32 format)
>+{
>+	switch (format) {
>+	case DRM_FORMAT_NV24:
>+	case DRM_FORMAT_NV30:
>+	case DRM_FORMAT_VUY888:
>+	case DRM_FORMAT_VUY101010:
>+		return true;
>+	default:
>+		return false;
>+	}
>+}
>+
> static bool vop2_afbc_uv_swap(u32 format)
> {
> 	switch (format) {
>@@ -1291,6 +1308,7 @@ static void vop2_plane_atomic_update(struct drm_plane *plane,
> 		 /* It's for head stride, each head size is 16 byte */
> 		stride = ALIGN(stride, block_w) / block_w * 16;
> 
>+		rb_swap = vop2_afbc_rb_swap(fb->format->format);
> 		uv_swap = vop2_afbc_uv_swap(fb->format->format);
> 		/*
> 		 * This is a workaround for crazy IC design, Cluster
>@@ -1308,6 +1326,7 @@ static void vop2_plane_atomic_update(struct drm_plane *plane,
> 			vop2_win_write(win, VOP2_WIN_AFBC_ENABLE, 1);
> 		vop2_win_write(win, VOP2_WIN_AFBC_FORMAT, afbc_format);
> 		vop2_win_write(win, VOP2_WIN_AFBC_UV_SWAP, uv_swap);
>+		vop2_win_write(win, VOP2_WIN_AFBC_RB_SWAP, rb_swap);
> 		/*
> 		 * On rk3566/8, this bit is auto gating enable,
> 		 * but this function is not work well so we need
>
>-- 
>2.52.0
>