From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 572C8D3EE60 for ; Thu, 22 Jan 2026 13:01:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=uaYzvb2XfnnkbyKx6FP5LwKsEl3/GXRkx9jsqA5CXcg=; b=EjKCMC3FF4TsMpK+F25mgvNOqT k9YJqfHJmDhWIWGQbHGCPLtC/eZNlVFhdYsZhCWeQxudy5IjYTLegFzYXAex4dRdfIRc0IecpehAH Z0JlJPyjGqonOcNZH/UPhl7jxkeGjPHGph7xJHUbjXeyAow8MmYHazCyUUNq4tkjB21wRygI2hICP nSOkSsS2ISRb9p9++O8WEv8dlaiEhABMucIKqNOj/6Gq60fDPGU3KIxlyt93OWsN2Aaqs0C24yg+2 w9cKsEOZaNwO569knXqkbdv5ZFw3fDZ1+P6Iq8+G0l1mh49LpGAg8AsFqXW5mA2JNsR2Ty6KQPRsg 97phthfg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1viuIx-000000076I3-0Gnt; Thu, 22 Jan 2026 13:00:55 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1viuIq-000000076HE-3gBc; Thu, 22 Jan 2026 13:00:50 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1769086792; cv=none; d=zohomail.com; s=zohoarc; b=VKqPDXZqQscCYPdjRAFzVjNUl2wWtTJSvTiRTzEYXbg2KRiiyrzw7Fgd5F4aj/GqLRkPG52NFbg+LSpLjs4GAECVbS01LsWvA9Fz1NjwIAPPjcU/3BNCDvAgEzXUnKfZB2evUSGJlSirmL7GTIXm02Roe2I5pcvUy99ppcqfscg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1769086792; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=uaYzvb2XfnnkbyKx6FP5LwKsEl3/GXRkx9jsqA5CXcg=; b=RJCKftJsR+YMsCXvoJUwTAO3XJ8vrGzxjCCYZQmDVjdkydhhqR4Bgvb/ZHdXIutEzxgIJnul+AxHTbyPdvbqJo6hzUNsBlNrvzLsDYiCWTGUDpqGZqeaDwo+5XzzCEUSynNz4SiSmXQzIFLwIW+bzQeySP1wgm4RvmR24fr4xfU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1769086792; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=uaYzvb2XfnnkbyKx6FP5LwKsEl3/GXRkx9jsqA5CXcg=; b=XQ+af+yjMhxPFVDC94pM4PlfhBu+gM6eH/bwFiy44r2PfvdSy4/Aodursm5Hdrqi VZ1oIeM9xzg5jXHXTAll2xKeZgInWMdf2dKrQIFjeVJqLYGJlLr9PJTsgJ/NoOlwVW6 ezT5oPGKFoHngWSi9Nrm67krvXYabnOVwbijhWko= Received: by mx.zohomail.com with SMTPS id 1769086791692511.35700158955376; Thu, 22 Jan 2026 04:59:51 -0800 (PST) From: Nicolas Frattaroli To: Andy Yan Cc: Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , Christian =?UTF-8?B?S8O2bmln?= , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Sandy Huang , Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Andy Yan , Jani Nikula , Rodrigo Vivi , Joonas Lahtinen , Tvrtko Ursulin , Dmitry Baryshkov , Sascha Hauer , Rob Herring , Jonathan Corbet , 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 Message-ID: <6631107.DvuYhMxLoT@workhorse> In-Reply-To: <7ab32c86.7542.19be4d21f69.Coremail.andyshrk@163.com> References: <20260121-color-format-v7-0-ef790dae780c@collabora.com> <20260121-color-format-v7-10-ef790dae780c@collabora.com> <7ab32c86.7542.19be4d21f69.Coremail.andyshrk@163.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260122_050049_025495_8A1F279E X-CRM114-Status: GOOD ( 20.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thursday, 22 January 2026 09:28:54 Central European Standard Time Andy Y= an wrote: >=20 > Hello Nicolas=EF=BC=8C >=20 > At 2026-01-21 22:45:17, "Nicolas Frattaroli" 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 > >--- > > 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_forma= t(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_forma= t(u32 format) > > return VOP2_AFBC_FMT_ARGB8888; > > case DRM_FORMAT_RGB888: > > case DRM_FORMAT_BGR888: > >+ case DRM_FORMAT_VUY888: >=20 > How did you test this format? It seems tools like modetest don=E2=80=99t = support testing this pattern. >=20 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=3DHDMI-A-1 color-format=3Dyuv444 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=3D8`. 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 >=20 >=20 > > 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) > > } > > } > >=20 > >+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_pl= ane *plane, > > /* It's for head stride, each head size is 16 byte */ > > stride =3D ALIGN(stride, block_w) / block_w * 16; > >=20 > >+ rb_swap =3D vop2_afbc_rb_swap(fb->format->format); > > uv_swap =3D 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_pl= ane *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 > > >=20