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 57F143148BF for ; Thu, 29 Jan 2026 01:29:57 +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=1769650199; cv=none; b=CNMfQFvqUr/ZKA2ZkIUHgdpukiBPiKuNp753B9OzRh65ILkXtu2BRFxy7O07XD4sdHqKFYUKldFVA1FLgKsAQvnzAVMAwIym5qL5qjpNFK7h9zvdADivFxTxjQsQQTbJ9TUYTNFfOVOYeaQI3uz+mmQencbTv4sk7gPPlKhwBqI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769650199; c=relaxed/simple; bh=h0ecRNsfJ1Ube1J+JZXHXMdInIH2cgiRidIImkm0O+k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GjeIQd8x/eEH/KRPa56bmAi0xJUn5lRIhsbVicsp5h5sWWjNye3g6SDY7pUJyB2SoG3QguB7DjeWEhKsh+xqR81UMWsLh/EX/3RUWMh3AeR1QpyvxWMAlCD96C1C32UOEAA/9F7Yqlos2NmsaS6Gj7MF46qSPilEsTwhZGMayg0= 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=neCo575Z; 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="neCo575Z" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1769650194; bh=h0ecRNsfJ1Ube1J+JZXHXMdInIH2cgiRidIImkm0O+k=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=neCo575Z4Za2yqJAuvx89d1Q/6/2VLrejV3axS35SX0sKtOAqMqdtBPPXzeEmgLIu 4CuXicCb/i5U7tRW3TxuhZvT6uTqJ/LlIFw5TylHXLAnNjj2OwHw+Old4hE3bXcvUt bKewde9m2KWTnFeWqVrI0b1OJdnMkllmby7/7s8YYXe+4+6hUJ8/2nskFYGY28uF8w F+ITG/7Cn6tql80E6DtFE+2bZ/h5N6sjJConXoAjjiJtS882mwFAWU+MGtVWQPwXCz Z6C3JUa4CSS5V8mE8Tff3WXtHdGHYuPh3qQpLVi0p/4+E59BZAG5HKBgSeVvg2346h lxbAKgCygUjtw== 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)) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id 274FB17E0699; Thu, 29 Jan 2026 02:29:54 +0100 (CET) Message-ID: <64633be5-4be9-469c-9164-c1d584ea4c7b@collabora.com> Date: Thu, 29 Jan 2026 03:29:53 +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 v5 4/4] drm/rockchip: vop2: Support setting custom background color To: Andy Shevchenko 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, Diederik de Haas References: <20260127-rk3588-bgcolor-v5-0-b25aa8613211@collabora.com> <20260127-rk3588-bgcolor-v5-4-b25aa8613211@collabora.com> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/27/26 4:45 PM, Andy Shevchenko wrote: > On Tue, Jan 27, 2026 at 10:45:36AM +0200, 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. > > ... > >> + /* >> + * Background color is programmed with 10 bits of precision. >> + * Since performance is more important than accuracy here, >> + * do *not* make use of the DRM_ARGB64_GET*_BPC() helpers. >> + */ >> + 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); > > There is FIELD_MODIFY() for a few cycles already. I've been aware, but found it more appropriate when modifying an existing value (e.g. previously read from a register) rather than when computing one from scratch. > But here it probably makes no much difference. Thinking again about this, it is actually handy when keeping the first FIELD_PREP (for initialization), and using it just for the subsequent operations. Hence considered this approach in v6. > ... > >> + seq_printf(s, "\tbackground color (10bpc): r=0x%x g=0x%x b=0x%x\n", >> + DRM_ARGB64_GETR(cstate->background_color) >> 6, >> + DRM_ARGB64_GETG(cstate->background_color) >> 6, >> + DRM_ARGB64_GETB(cstate->background_color) >> 6); > > Probably you want to have the alternative to the DRM_ARGB64_GETx() macros which > incorporates a right-shift. But it all in regard to DRM style and preferences. I tried to keep the API as simple as possible, but you're right, it's better to have those macros rather than open-coding the bit-shift all over. Also handled in v6. Thanks again, Cristian