From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Andy Yan <andyshrk@163.com>
Cc: "Harry Wentland" <harry.wentland@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <siqueira@igalia.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Andrzej Hajda" <andrzej.hajda@intel.com>,
"Neil Armstrong" <neil.armstrong@linaro.org>,
"Robert Foss" <rfoss@kernel.org>,
"Laurent Pinchart" <Laurent.pinchart@ideasonboard.com>,
"Jonas Karlman" <jonas@kwiboo.se>,
"Jernej Skrabec" <jernej.skrabec@gmail.com>,
"Sandy Huang" <hjc@rock-chips.com>,
"Heiko Stübner" <heiko@sntech.de>,
"Andy Yan" <andy.yan@rock-chips.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Dmitry Baryshkov" <lumag@kernel.org>,
"Sascha Hauer" <s.hauer@pengutronix.de>,
"Rob Herring" <robh@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
kernel@collabora.com, amd-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v7 10/22] drm/rockchip: vop2: Fix YUV444 output
Date: Thu, 22 Jan 2026 13:59:41 +0100 [thread overview]
Message-ID: <6631107.DvuYhMxLoT@workhorse> (raw)
In-Reply-To: <7ab32c86.7542.19be4d21f69.Coremail.andyshrk@163.com>
On Thursday, 22 January 2026 09:28:54 Central European Standard Time Andy Yan wrote:
>
> Hello Nicolas,
>
> At 2026-01-21 22:45:17, "Nicolas Frattaroli" <nicolas.frattaroli@collabora.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@collabora.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.
>
Hi Andy,
using the rest of this series, which implements the "color format"
DRM property, and the corresponding weston MR that makes use of it[1].
I create a ~/.config/weston.ini with the following contents:
[output]
name=HDMI-A-1
color-format=yuv444
This will make Weston try to set the output format to 10-bit YUV444. To
limit it to 8-bit, you can add `max-bpc=8`. The monitor's EDID needs to
report YUV444 support, otherwise that Weston version won't let you set
this property.
Link: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1859 [1]
Kind regards,
Nicolas Frattaroli
>
>
> > 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
> >
>
next prev parent reply other threads:[~2026-01-22 13:01 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 14:45 [PATCH v7 00/22] Add new general DRM property "color format" Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 01/22] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 02/22] drm: Add new general DRM property "color format" Nicolas Frattaroli
2026-02-06 14:05 ` Maxime Ripard
2026-02-06 15:26 ` Nicolas Frattaroli
2026-02-10 17:03 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 03/22] drm: Add enum conversions between DRM_COLOR_FORMAT and HDMI_COLORSPACE Nicolas Frattaroli
2026-02-06 14:08 ` Maxime Ripard
2026-02-07 19:55 ` Nicolas Frattaroli
2026-02-10 17:24 ` Maxime Ripard
2026-02-11 17:10 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 04/22] drm/bridge: Act on the DRM color format property Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 05/22] drm/display: hdmi-state-helper: Act on color format DRM property Nicolas Frattaroli
2026-02-06 14:16 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 06/22] drm/display: hdmi-state-helper: Try subsampling in mode_valid Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 07/22] drm/i915: Implement the "color format" DRM property Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 08/22] drm/amdgpu: Implement " Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 09/22] drm/rockchip: Add YUV422 output mode constants for VOP2 Nicolas Frattaroli
2026-01-22 6:30 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 10/22] drm/rockchip: vop2: Fix YUV444 output Nicolas Frattaroli
2026-01-22 8:28 ` Andy Yan
2026-01-22 12:59 ` Nicolas Frattaroli [this message]
2026-01-23 1:29 ` Re:Re: [PATCH " Andy Yan
2026-02-07 19:31 ` Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 11/22] drm/rockchip: vop2: Add RK3576 to the RG swap special case Nicolas Frattaroli
2026-01-22 8:31 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 12/22] drm/rockchip: vop2: Recognise 10/12-bit YUV422 as YUV formats Nicolas Frattaroli
2026-01-22 8:42 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 13/22] drm/rockchip: vop2: Set correct output format for RK3576 YUV422 Nicolas Frattaroli
2026-01-22 8:44 ` Andy Yan
2026-01-21 14:45 ` [PATCH v7 14/22] drm/bridge: dw-hdmi-qp: Implement atomic_get_output_bus_fmts Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 15/22] drm/rockchip: dw_hdmi_qp: Implement "color format" DRM property Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 16/22] drm/rockchip: dw_hdmi_qp: Set supported_formats platdata Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 17/22] drm/connector: Register color format property on HDMI connectors Nicolas Frattaroli
2026-01-21 14:45 ` [PATCH v7 18/22] drm/tests: hdmi: Add tests for the color_format property Nicolas Frattaroli
2026-02-10 15:51 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 19/22] drm/tests: hdmi: Add tests for HDMI helper's mode_valid Nicolas Frattaroli
2026-02-10 15:52 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 20/22] drm/tests: edid: Add __maybe_unused attribute to EDID definitions Nicolas Frattaroli
2026-02-10 16:00 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 21/22] drm/tests: bridge: Add KUnit tests for bridge chain format selection Nicolas Frattaroli
2026-02-10 16:11 ` Maxime Ripard
2026-01-21 14:45 ` [PATCH v7 22/22] drm/bridge: Document " Nicolas Frattaroli
2026-02-10 16:25 ` Maxime Ripard
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=6631107.DvuYhMxLoT@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrzej.hajda@intel.com \
--cc=andy.yan@rock-chips.com \
--cc=andyshrk@163.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=heiko@sntech.de \
--cc=hjc@rock-chips.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=s.hauer@pengutronix.de \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.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