Hi Andy,

On 2/13/26 9:07 AM, Andy Yan wrote:

Hello Cristian，

At 2026-01-16 23:22:11, "Cristian Ciocaltea" [off-list ref] wrote:

quoted

On 1/10/26 11:58 AM, Cristian Ciocaltea wrote:

quoted

Hi Andy,

On 1/10/26 6:00 AM, Andy Yan wrote:

quoted

Hello Cristian,
At 2025-12-20 05:47:01, "Cristian Ciocaltea" [off-list ref] wrote:

quoted

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 <redacted>
---
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(-)

[...]

quoted

quoted

quoted

quoted

-	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)

quoted

quoted

6);

quoted

+	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.

I performed several tests on my ROCK 3A (RK3568), ROCK 4D (RK3576) and ROCK
5B (RK3588) boards and noticed that by setting bg_display_en bit to 1 or 0
doesn't have any influence on RK3568 and RK3576, the background color is
always active and cannot be disabled.

However, flipping the bit to 1 on RK3588 has the unexpected effect of
covering the whole screen with the configured color, even when there's an
active plane displayed on top. Switching back to 0 makes it work as expected.

Therefore I think we should keep this patch as is, unless there's something
else we're missing here.

quoted

quoted

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.

Considering the observation above, it kinda makes sense now for RK3588 to
default to 0.

   I further confirmed with our IC team: for RK3588, RK3528, and RK3562, if
   the display_enbit is set, the background color will indeed cover all
   layers. For other chips, this bit has no effect. So ACK

Thanks for clarifying!  

This patch is the only one in the series missing a review, hence could you
please provide your R-b (or A-b) tag on the last revision [1]? 

Regards,
Cristian

[1] https://lore.kernel.org/all/20260204-rk3588-bgcolor-v7-4-78d1d01c5ca1@collabora.com/ (local)