public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Jaehoon Chung" <jh80.chung@samsung.com>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Shreeya Patel" <shreeya.patel@collabora.com>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Sandy Huang" <hjc@rock-chips.com>,
	"Andy Yan" <andy.yan@rock-chips.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Nicolas Frattaroli" <frattaroli.nicolas@gmail.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Jaroslav Kysela" <perex@perex.cz>,
	"Takashi Iwai" <tiwai@suse.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Shawn Lin" <shawn.lin@rock-chips.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Chanwoo Choi" <cw00.choi@samsung.com>,
	"MyungJoo Ham" <myungjoo.ham@samsung.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Qin Jian" <qinjian@cqplus1.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <nick.desaulniers+lkml@gmail.com>,
	"Bill Wendling" <morbo@google.com>,
	"Justin Stitt" <justinstitt@google.com>
Cc: Tvrtko Ursulin <tursulin@igalia.com>,
	linux-pm@vger.kernel.org, netdev@vger.kernel.org,
	llvm@lists.linux.dev, linux-mmc@vger.kernel.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-clk@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-sound@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-phy@lists.infradead.org, kernel@collabora.com,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 01/20] bitfield: introduce HWORD_UPDATE bitfield macros
Date: Fri, 13 Jun 2025 11:51:15 +0300	[thread overview]
Message-ID: <5493fd6017de3f393f632125fad95945d1c4294c@intel.com> (raw)
In-Reply-To: <20250612-byeword-update-v1-1-f4afb8f6313f@collabora.com>

On Thu, 12 Jun 2025, Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> Hardware of various vendors, but very notably Rockchip, often uses
> 32-bit registers where the upper 16-bit half of the register is a
> write-enable mask for the lower half.
>
> This type of hardware setup allows for more granular concurrent register
> write access.
>
> Over the years, many drivers have hand-rolled their own version of this
> macro, usually without any checks, often called something like
> HIWORD_UPDATE or FIELD_PREP_HIWORD, commonly with slightly different
> semantics between them.
>
> Clearly there is a demand for such a macro, and thus the demand should
> be satisfied in a common header file.
>
> Add two macros: HWORD_UPDATE, and HWORD_UPDATE_CONST. The latter is a
> version that can be used in initializers, like FIELD_PREP_CONST. The
> macro names are chosen to not clash with any potential other macros that
> drivers may already have implemented themselves, while retaining a
> familiar name.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  include/linux/bitfield.h | 47 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
>
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index 6d9a53db54b66c0833973c880444bd289d9667b1..b90d88db7405f95b78cdd6f3426263086bab5aa6 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -8,6 +8,7 @@
>  #define _LINUX_BITFIELD_H
>  
>  #include <linux/build_bug.h>
> +#include <linux/limits.h>
>  #include <linux/typecheck.h>
>  #include <asm/byteorder.h>
>  
> @@ -142,6 +143,52 @@
>  		(((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask))	\
>  	)
>  
> +/**
> + * HWORD_UPDATE() - prepare a bitfield element with a mask in the upper half
> + * @_mask: shifted mask defining the field's length and position
> + * @_val:  value to put in the field
> + *
> + * HWORD_UPDATE() masks and shifts up the value, as well as bitwise ORs the
> + * result with the mask shifted up by 16.
> + *
> + * This is useful for a common design of hardware registers where the upper
> + * 16-bit half of a 32-bit register is used as a write-enable mask. In such a
> + * register, a bit in the lower half is only updated if the corresponding bit
> + * in the upper half is high.
> + */
> +#define HWORD_UPDATE(_mask, _val)					 \
> +	({								 \
> +		__BF_FIELD_CHECK(_mask, ((u16) 0U), _val,		 \
> +				 "HWORD_UPDATE: ");			 \
> +		(((typeof(_mask))(_val) << __bf_shf(_mask)) & (_mask)) | \
> +		((_mask) << 16);					 \
> +	})

i915 uses something like this for a few registers too, with the name
_MASKED_FIELD(). I think we could use it.

I do think this is clearly an extension of FIELD_PREP(), though, and
should be be named similarly, instead of the completely deviating
HWORD_UPDATE().

Also, we recently got GENMASK() versions with sizes, GENMASK_U16()
etc. so I find it inconsistent to denote size here with HWORD.

FIELD_PREP_MASKED_U16? MASKED_FIELD_PREP_U16? Something along those
lines?

And perhaps that (and more potential users) could persuade Jakub that
this is not that weird after all?


BR,
Jani.




> +
> +/**
> + * HWORD_UPDATE_CONST() - prepare a constant bitfield element with a mask in
> + *                        the upper half
> + * @_mask: shifted mask defining the field's length and position
> + * @_val:  value to put in the field
> + *
> + * HWORD_UPDATE_CONST() masks and shifts up the value, as well as bitwise ORs
> + * the result with the mask shifted up by 16.
> + *
> + * This is useful for a common design of hardware registers where the upper
> + * 16-bit half of a 32-bit register is used as a write-enable mask. In such a
> + * register, a bit in the lower half is only updated if the corresponding bit
> + * in the upper half is high.
> + *
> + * Unlike HWORD_UPDATE(), this is a constant expression and can therefore
> + * be used in initializers. Error checking is less comfortable for this
> + * version.
> + */
> +#define HWORD_UPDATE_CONST(_mask, _val)					  \
> +	(								  \
> +		FIELD_PREP_CONST(_mask, _val) |				  \
> +		(BUILD_BUG_ON_ZERO(const_true((u64) (_mask) > U16_MAX)) + \
> +		 ((_mask) << 16))					  \
> +	)
> +
>  /**
>   * FIELD_GET() - extract a bitfield element
>   * @_mask: shifted mask defining the field's length and position

-- 
Jani Nikula, Intel

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2025-06-13  8:54 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-12 18:56 [PATCH 00/20] BYEWORD_UPDATE: unifying (most) HIWORD_UPDATE macros Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 01/20] bitfield: introduce HWORD_UPDATE bitfield macros Nicolas Frattaroli
2025-06-12 19:44   ` Jakub Kicinski
2025-06-12 19:50     ` Nicolas Frattaroli
2025-06-12 20:10       ` Yury Norov
2025-06-12 22:01         ` Jakub Kicinski
2025-06-13  8:51   ` Jani Nikula [this message]
2025-06-13 11:55     ` Nicolas Frattaroli
2025-06-13 12:28       ` Yury Norov
2025-06-13 14:59         ` Jakub Kicinski
2025-06-13 13:54   ` Robin Murphy
2025-06-13 14:52     ` Yury Norov
2025-06-16 12:27       ` Nicolas Frattaroli
2025-06-16 13:26         ` Jani Nikula
2025-06-12 18:56 ` [PATCH 02/20] mmc: dw_mmc-rockchip: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-16 13:29   ` Ulf Hansson
2025-06-12 18:56 ` [PATCH 03/20] soc: rockchip: grf: switch to HWORD_UPDATE_CONST macro Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 04/20] media: synopsys: hdmirx: replace macros with bitfield variants Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 05/20] drm/rockchip: lvds: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 06/20] phy: rockchip-emmc: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 07/20] drm/rockchip: dsi: switch to HWORD_UPDATE* macros Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 08/20] drm/rockchip: vop2: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-13  9:55   ` Cristian Ciocaltea
2025-06-12 18:56 ` [PATCH 09/20] phy: rockchip-samsung-dcphy: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 10/20] drm/rockchip: dw_hdmi_qp: " Nicolas Frattaroli
2025-06-13 10:08   ` Cristian Ciocaltea
2025-06-12 18:56 ` [PATCH 11/20] drm/rockchip: inno-hdmi: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 12/20] phy: rockchip-usb: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 13/20] drm/rockchip: dw_hdmi: switch to HWORD_UPDATE* macros Nicolas Frattaroli
2025-06-13 10:15   ` Cristian Ciocaltea
2025-06-12 18:56 ` [PATCH 14/20] ASoC: rockchip: i2s-tdm: switch to HWORD_UPDATE_CONST macro Nicolas Frattaroli
2025-06-13 11:12   ` Mark Brown
2025-06-12 18:56 ` [PATCH 15/20] net: stmmac: dwmac-rk: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-12 19:08   ` Andrew Lunn
2025-06-12 19:16     ` Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 16/20] PCI: rockchip: switch to HWORD_UPDATE* macros Nicolas Frattaroli
2025-06-12 19:37   ` Bjorn Helgaas
2025-06-12 19:52     ` Yury Norov
2025-06-12 18:56 ` [PATCH 17/20] PCI: dw-rockchip: switch to HWORD_UPDATE macro Nicolas Frattaroli
2025-06-12 19:38   ` Bjorn Helgaas
2025-06-13  9:45   ` Niklas Cassel
2025-06-13 12:08     ` Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 18/20] PM / devfreq: rockchip-dfi: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 19/20] clk: sp7021: " Nicolas Frattaroli
2025-06-12 18:56 ` [PATCH 20/20] phy: rockchip-pcie: " Nicolas Frattaroli
2025-06-12 19:45 ` [PATCH 00/20] BYEWORD_UPDATE: unifying (most) HIWORD_UPDATE macros Yury Norov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5493fd6017de3f393f632125fad95945d1c4294c@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andy.yan@rock-chips.com \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=davem@davemloft.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=edumazet@google.com \
    --cc=frattaroli.nicolas@gmail.com \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=jh80.chung@samsung.com \
    --cc=justinstitt@google.com \
    --cc=kernel@collabora.com \
    --cc=kishon@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@rasmusvillemoes.dk \
    --cc=llvm@lists.linux.dev \
    --cc=lpieralisi@kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mani@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=morbo@google.com \
    --cc=mripard@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=nathan@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=pabeni@redhat.com \
    --cc=perex@perex.cz \
    --cc=qinjian@cqplus1.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=shreeya.patel@collabora.com \
    --cc=simona@ffwll.ch \
    --cc=tiwai@suse.com \
    --cc=tursulin@igalia.com \
    --cc=tzimmermann@suse.de \
    --cc=ulf.hansson@linaro.org \
    --cc=vkoul@kernel.org \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox