[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9e4c8514-63e9-4ff7-85b1-b5af7dff9a2d@collabora.com>
Date: Sat, 10 Jan 2026 11:58:08 +0200
From: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
To: Andy Yan <andyshrk@....com>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Sandy Huang <hjc@...k-chips.com>, Heiko Stübner
<heiko@...ech.de>, Andy Yan <andy.yan@...k-chips.com>,
Louis Chauvet <louis.chauvet@...tlin.com>,
Haneen Mohammed <hamohammed.sa@...il.com>,
Melissa Wen <melissa.srw@...il.com>,
Robert Mader <robert.mader@...labora.com>, kernel@...labora.com,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH v4 4/4] drm/rockchip: vop2: Support setting custom
background color
Hi Andy,
On 1/10/26 6:00 AM, Andy Yan wrote:
>
>
> Hello Cristian,
> At 2025-12-20 05:47:01, "Cristian Ciocaltea" <cristian.ciocaltea@...labora.com> wrote:
>> The Rockchip VOP2 display controller allows configuring the background
>> color of each video output port.
>>
>> Since a previous patch introduced the BACKGROUND_COLOR CRTC property,
>> which defaults to solid black, make use of it when programming the
>> hardware.
>>
>> Note the maximum precision allowed by the display controller is 10bpc,
>> while the alpha component is not supported, hence ignored.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 13 ++++++++++++-
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 4 ++++
>> 2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> index 498df0ce4680..3a232d0d4acb 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> @@ -1554,6 +1554,7 @@ static void vop2_post_config(struct drm_crtc *crtc)
>> struct vop2_video_port *vp = to_vop2_video_port(crtc);
>> struct vop2 *vop2 = vp->vop2;
>> struct drm_display_mode *mode = &crtc->state->adjusted_mode;
>> + u64 bgcolor = crtc->state->background_color;
>> u16 vtotal = mode->crtc_vtotal;
>> u16 hdisplay = mode->crtc_hdisplay;
>> u16 hact_st = mode->crtc_htotal - mode->crtc_hsync_start;
>> @@ -1599,7 +1600,11 @@ static void vop2_post_config(struct drm_crtc *crtc)
>> vop2_vp_write(vp, RK3568_VP_POST_DSP_VACT_INFO_F1, val);
>> }
>>
>> - vop2_vp_write(vp, RK3568_VP_DSP_BG, 0);
>> + /* Background color is programmed with 10 bits of precision */
>> + val = FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_RED, DRM_ARGB64_GETR(bgcolor) >> 6);
>> + val |= FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_GREEN, DRM_ARGB64_GETG(bgcolor) >> 6);
>
>> + val |= FIELD_PREP(RK3568_VP_DSP_BG__DSP_BG_BLUE, DRM_ARGB64_GETB(bgcolor) >> 6);
>
>
> the bit31 of RK3568_VP_DSP_BG is bg_display_en, that means when we set a
> background color, we should set this bg_display_en bit.
Oh yes, good catch!
> The default value of this bit is 1, which explains why the patch currently works
> properly even though it doesn't set bit31.
For some reason, the RK3588 TRM indicates 0x0 for the reset value. I assume
that's a mistake, as RK3576 TRM shows 0x1.
Thanks,
Cristian
Powered by blists - more mailing lists