Hi Andy, On 2/13/26 9:07 AM, Andy Yan wrote: > Hello Cristian， > > At 2026-01-16 23:22:11, "Cristian Ciocaltea" > <[email protected]> wrote: >> On 1/10/26 11:58 AM, Cristian Ciocaltea wrote: >>> Hi Andy, >>> >>> On 1/10/26 6:00 AM, Andy Yan wrote: >>>> >>>> >>>> Hello Cristian, >>>> At 2025-12-20 05:47:01, "Cristian Ciocaltea" >>>> <[email protected]> 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 <[email protected]> >>>>> --- >>>>> 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(-)
[...] >>>>> - 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. >> >> 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. >> >>>> 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/[email protected]/
