From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 007C4D358EC for ; Thu, 29 Jan 2026 09:38:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+MG5VXP11LK6mhmevNe/+r9IB8BAaPjhL02h1bybnUw=; b=qXP5D5S0HUPmYw EEfNhbkM3rM0vDrT9V8H3Gh9+wRCwO+frEYFVjPvzFJXQ+CcdqzNyKDCGGnpwDdNWQ+5gLIkbZT52 0bQGJen45Z1GqODh3zGpUX2nxvOp/7i2OgEEMv4g9rp9WTsf5RmFHg8WYfgmnZjN95vYeb6A17aUV QwN5ewQAc0vIZNEJi1qFW+lYPH7lzVIFbONP5gYESlkgt0D3u0CRk4qAeEAhagOGIa8NgUKxnFkfL JBldUToAW0uiZ2IRx7G6KzhnlFa9aZk2tT6ZWMVVOuGW729abCIWHJbTT/1AFBBB4sBqRs2h6cU7Z ew5nFwGuO2K39xYKThcQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vlOTL-0000000HWf0-1ZKY; Thu, 29 Jan 2026 09:37:55 +0000 Received: from mgamail.intel.com ([198.175.65.16]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vlOTI-0000000HWdz-2fKJ; Thu, 29 Jan 2026 09:37:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769679473; x=1801215473; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fcH4mUDNyS5wydLrVZXUX/K4ZKaotkjSpo0HtMsk+1o=; b=lVGPwfTSy0eOth5F5bjSFiLDm8t0sZOIEE8lC0BJmJ9fpuPGqZYiruTS Xj1lM6ZGm6xdbTQoP2A0hcW6QvZdqcKE7KkUwPR1HJrPCqtgUns96JwmB NAZCIv//SNVoJR9TG481GqUqmNW0qJttZ8F+YDCuyYqyjdbmMUFEUHaWN inltHv94RieOdeNd8/x8BWiyIT/Iwj18FHejILHUmlNkfsXF/Zoz8yNXF fZ7p0i9DCDKMJm0cEGaptg2j+M+e01bwyd+eqjyNItRfd0SkvKcza/ZjM G/tLVwYqf8zl211U0Rmjg5e0OY4MwI1w/FQEvtkvAKqR/MyQ3dyewT64H g==; X-CSE-ConnectionGUID: 8yTWqO0nQS6EGbu68HInPQ== X-CSE-MsgGUID: dW1SyljrRviCPMduZp953A== X-IronPort-AV: E=McAfee;i="6800,10657,11685"; a="71074878" X-IronPort-AV: E=Sophos;i="6.21,260,1763452800"; d="scan'208";a="71074878" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2026 01:37:50 -0800 X-CSE-ConnectionGUID: Q6oB1hS4RWCJLoDv2BxPDA== X-CSE-MsgGUID: vyc3EwQqRieVpm72pc7e7w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,260,1763452800"; d="scan'208";a="246133392" Received: from klitkey1-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.155]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2026 01:37:29 -0800 Date: Thu, 29 Jan 2026 11:37:22 +0200 From: Andy Shevchenko To: Cristian Ciocaltea Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sandy Huang , Heiko =?iso-8859-1?Q?St=FCbner?= , Andy Yan , Louis Chauvet , Haneen Mohammed , Melissa Wen , Jani Nikula , 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, Matt Roper , =?iso-8859-1?Q?N=EDcolas_F=2E_R=2E_A=2E?= Prado , Diederik de Haas Subject: Re: [PATCH v6 2/4] drm: Add CRTC background color property Message-ID: References: <20260129-rk3588-bgcolor-v6-0-c15f755a4055@collabora.com> <20260129-rk3588-bgcolor-v6-2-c15f755a4055@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20260129-rk3588-bgcolor-v6-2-c15f755a4055@collabora.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260129_013752_752197_CA2E37FD X-CRM114-Status: GOOD ( 23.83 ) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+linux-rockchip=archiver.kernel.org@lists.infradead.org On Thu, Jan 29, 2026 at 02:58:52AM +0200, Cristian Ciocaltea wrote: > Some display controllers can be hardware programmed to show non-black > colors for pixels that are either not covered by any plane or are > exposed through transparent regions of higher planes. This feature can > help reduce memory bandwidth usage, e.g. in compositors managing a UI > with a solid background color while using smaller planes to render the > remaining content. > > To support this capability, introduce the BACKGROUND_COLOR standard DRM > mode property, which can be attached to a CRTC through the > drm_crtc_attach_background_color_property() helper function. > > Additionally, define a 64-bit ARGB format value to be built with the > help of a couple of dedicated DRM_ARGB64_PREP*() helpers. Individual > color components can be extracted with desired precision using the > corresponding DRM_ARGB64_GET*() macros. ... > +/* > + * Put 16-bit ARGB values into a standard 64-bit representation that can be > + * used for ioctl parameters, inter-driver communication, etc. > + * > + * If the component values being provided contain less than 16 bits of > + * precision, use a conversion ratio to get a better color approximation. > + * The ratio is computed as (2^16 - 1) / (2^bpc - 1), where bpc and 16 are > + * the input and output precision, respectively. Not sure if you should explicitly mention that "bpc must not be 0" (it can be derived from the "division by 0" in the given formula, but still...). > + */ > +#define __DRM_ARGB64_PREP(c, shift) \ > + (((__u64)(c) & __GENMASK(15, 0)) << (shift)) > + > +#define __DRM_ARGB64_PREP_BPC(c, shift, bpc)({ \ Not sure if this is an accepted style in DRM, by I find it difficult to follow. I would expect the "({" be on a separate line. > + __u16 mask = __GENMASK((bpc) - 1, 0); \ > + __u16 conv = __KERNEL_DIV_ROUND_CLOSEST((mask & (c)) * \ > + __GENMASK(15, 0), mask);\ The whole point of the first patch is to use it in the divisions by 2^n - 1. Can we transform this to make it "divisions" by power-of-two? ...: def dbm2(c, bpc): ...: m = (1 << bpc) - 1 ...: c1 = m & c ...: r = c1 << (16 - bpc) ...: for i in range(1, 16 // bpc): ...: r = r + (c1 << (16 - (i + 1) * bpc)) ...: return r The above is a Python version of PoC of this approximation. Basically we transform the fraction X / (2^n - 1) to a chained version of X / 2^n + X / 2^2n + ... X / 2^kn as derived from recurrent formula of i+1:th iteration as Xi+1 = Xi / 2^n + Xi / (2^n * (2^n - 1)). So, maybe that one should be used instead? (It may be thought through on how to collapse the for-loop to maybe some bitops, but even with a for-loop it might be faster than real division.) Note, we have some (for sure more than one, I remember the same Q appeared to me a few years ago) of the examples which may avoid division at all. I would like to have this macro to be kernel wide (and UAPI seems also okay). > + __DRM_ARGB64_PREP(conv, shift); \ > +}) -- With Best Regards, Andy Shevchenko _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip