From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (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 6C26337FF74 for ; Thu, 29 Jan 2026 09:37:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769679472; cv=none; b=BmeMOfLxpuJ5dBgxwaHNiL3XWeRAwT6eEUd3BYzzz3DVt8MW5m6kWEZ82mR2mMWGibyfeG+U2M34uZfaNjHRaPjQWSfcuOdlCEOe3uxXJwuRPHiY03VtXDQiTaedvxMxHi7qHobqBIlxpIA3aN0JGFV3isdBur0NlbpJrncdJuE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769679472; c=relaxed/simple; bh=fcH4mUDNyS5wydLrVZXUX/K4ZKaotkjSpo0HtMsk+1o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ArWGdncjmO00iK5+lSl6eucB8+YBjePAvZbGPs/Cyn3XJAe8tHGB3l9xu329rvr/FlrsRcAIi88px8qMyJx093wirLmsAC71rxeFiJI/LIE+S/GQU68i2HC0MHt+l33AYTGD7ZQTGrRQhjInVUNu9aGHAmXBhpyHoX4Wz4prNEo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Sqr8Gfqd; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Sqr8Gfqd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769679471; x=1801215471; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fcH4mUDNyS5wydLrVZXUX/K4ZKaotkjSpo0HtMsk+1o=; b=Sqr8GfqdDxpU6PVhdvF2rH3etLLl1MdARKBZ7KjRDykxFBa4hPAgmQFE 3rawpZCEBwX8tSjvMOnG17PHkXThHcPvcNHKkMbX6jO5mtL+irOnW4WxC jrb+yszPT+59gkx+12MrPbY9HpLNt023bGubSLxgLihcsY2+Xvq9pMaUr AR7DNg0OaCbH96Hza76IJ2MDp7lMPiF82ptL60Do0Yyhu/N6ZXYUXorl9 UmP1cU2Hvy8GBBEboGI0aplFupeOW3Ts4KxV3OTFdwPs2JOcQ64B45ckG apHvWazmLRvDmelwMm+e6fDxsTyVOANlTvrH6dphwsheen6p0rhIs+C5g A==; X-CSE-ConnectionGUID: QDOTDnQeRN2Fufrm9Tgx8Q== X-CSE-MsgGUID: 7S+lGeMdQyKzukBbBw/hQg== X-IronPort-AV: E=McAfee;i="6800,10657,11685"; a="71074873" X-IronPort-AV: E=Sophos;i="6.21,260,1763452800"; d="scan'208";a="71074873" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 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