From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1819F212550 for ; Fri, 13 Feb 2026 11:04:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770980660; cv=none; b=kLyqqer0/n6nlmBBoEJ9+usoR8UUEsQIBRqdBaZzoZhAcWinJrgYnv4wJTjOdqPrQpiJuHpvnlMSo8HoOsO2Jjqg9ktGk94PWf9tbYCXmKZLmXXdZF8tbotLgq4fMGm9BZc9g99HlmGtnRv7PvafDzwztS3pobh7yOGvyiQV010= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770980660; c=relaxed/simple; bh=4nZFI6B+4DaZ1xwgKXUjqRowetvZjkztwjYyqHMz+xc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=C3BFKgXt9GejAO5RJIf6VnkrabUvNTN5YzFJmPAy0TODrUPPguqOz3zCl/v6a9OL1W7JqO77hkEaYIQeNsxRcgcLAfRHDYW1NTbclimCWvR3GF2/do8LOI6RtZYQlE3iz8vyVZ926WTXKDXeXY5Ks+MlIqthztILbElrKQ7CA+A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=plpyxtUI; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="plpyxtUI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1770980657; bh=4nZFI6B+4DaZ1xwgKXUjqRowetvZjkztwjYyqHMz+xc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=plpyxtUIxFe/gOImlgAHoJUSgVdLvn0eJMXXj/FJyqzIalCK1zIypr0FQ1HGJ1pAY 3jUR1T9E4is+Xl8N6JbB/VRPv7MsKU5+j0vmn2JyNglpCU2cE5iS1l3xTAuhuIWZdr zTUxqpABXVdGZDyZWcLcwXosI8VcXrm0GDQWJvxB9pNXEBYLgXrWIvoeFy+QblZR61 pJFzBWwLlgs70SJ6t/5WgXMN0faGiFqECbVfofSI9U4Xxtfter8u3iERgGxBCt+Kq2 l6SxBhdXnys+wtZtINxvexBOgSd/WW9dk1ljzueIJh0+RXPUc0ogy0bjladzq17/aO FAnQ+k1oNXTOA== Received: from [192.168.1.90] (unknown [82.79.138.145]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id 9B4A217E1406; Fri, 13 Feb 2026 12:04:16 +0100 (CET) Message-ID: Date: Fri, 13 Feb 2026 13:04:16 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 4/4] drm/rockchip: vop2: Support setting custom background color To: Andy Yan Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan , Louis Chauvet , Haneen Mohammed , Melissa Wen , Robert Mader , kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org References: <20251219-rk3588-bgcolor-v4-0-2ff1127ea757@collabora.com> <20251219-rk3588-bgcolor-v4-4-2ff1127ea757@collabora.com> <2750b73.10b0.19ba61052c8.Coremail.andyshrk@163.com> <9e4c8514-63e9-4ff7-85b1-b5af7dff9a2d@collabora.com> <67fb66b7-eee7-4109-8127-385593e88425@collabora.com> <539febc7.2cf9.19c55d3dfb0.Coremail.andyshrk@163.com> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: <539febc7.2cf9.19c55d3dfb0.Coremail.andyshrk@163.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Andy, On 2/13/26 9:07 AM, Andy Yan wrote: > Hello Cristian， > > At 2026-01-16 23:22:11, "Cristian Ciocaltea" 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" 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 >>>>> --- >>>>> 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/20260204-rk3588-bgcolor-v7-4-78d1d01c5ca1@collabora.com/