[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2188729.OBFZWjSADL@diego>
Date: Sat, 31 May 2025 23:48:29 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Linus Walleij <linus.walleij@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Uwe Kleine-König <ukleinek@...nel.org>,
William Breathitt Gray <wbg@...nel.org>,
Sebastian Reichel <sebastian.reichel@...labora.com>,
Kever Yang <kever.yang@...k-chips.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-pwm@...r.kernel.org,
linux-iio@...r.kernel.org, kernel@...labora.com,
Jonas Karlman <jonas@...boo.se>,
Detlev Casanova <detlev.casanova@...labora.com>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: Re: [PATCH 4/7] soc: rockchip: add mfpwm driver
Am Dienstag, 8. April 2025, 14:32:16 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> With the Rockchip RK3576, the PWM IP used by Rockchip has changed
> substantially. Looking at both the downstream pwm-rockchip driver as
> well as the mainline pwm-rockchip driver made it clear that with all its
> additional features and its differences from previous IP revisions, it
> is best supported in a new driver.
>
> This brings us to the question as to what such a new driver should be.
> To me, it soon became clear that it should actually be several new
> drivers, most prominently when Uwe Kleine-König let me know that I
> should not implement the pwm subsystem's capture callback, but instead
> write a counter driver for this functionality.
>
> Combined with the other as-of-yet unimplemented functionality of this
> new IP, it became apparent that it needs to be spread across several
> subsystems.
>
> For this reason, we add a new platform bus based driver, called mfpwm
> (short for "Multi-function PWM"). This "parent" driver makes sure that
> only one device function driver is using the device at a time, and is in
> charge of registering the platform bus devices for the individual device
> functions offered by the device.
>
> An acquire/release pattern is used to guarantee that device function
> drivers don't step on each other's toes.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
actually trying to compile this, led me to
aarch64-linux-gnu-ld: drivers/soc/rockchip/mfpwm.o: in function `mfpwm_reg_read':
/home/devel/hstuebner/00_git-repos/linux-rockchip/_build-arm64/../include/soc/rockchip/mfpwm.h:423: multiple definition of `mfpwm_reg_read'; drivers/pwm/pwm-rockchip-v4.o:/home/devel/hstuebner/00_git-repos/linux-rockchip/_build-arm64/../include/soc/rockchip/mfpwm.h:423: first defined here
aarch64-linux-gnu-ld: drivers/soc/rockchip/mfpwm.o: in function `mfpwm_reg_write':
/home/devel/hstuebner/00_git-repos/linux-rockchip/_build-arm64/../include/soc/rockchip/mfpwm.h:428: multiple definition of `mfpwm_reg_write'; drivers/pwm/pwm-rockchip-v4.o:/home/devel/hstuebner/00_git-repos/linux-rockchip/_build-arm64/../include/soc/rockchip/mfpwm.h:428: first defined here
make[3]: *** [../scripts/Makefile.vmlinux_o:72: vmlinux.o] Fehler 1
during the linking stage - with the driver as builtin
> +inline u32 mfpwm_reg_read(void __iomem *base, u32 reg)
> +{
> + return readl(base + reg);
> +}
> +
> +inline void mfpwm_reg_write(void __iomem *base, u32 reg, u32 val)
> +{
> + writel(val, base + reg);
> +}
making that a "static inline ..." solves that.
On a more general note, what is the differentiation to an MFD here?
Like you can already bind dt-nodes to MFD subdevices, and can implement
the exclusivity API thing on top of a general mfd device, to make sure only
one mfd-cell gets activated at one time.
Other than that, this looks like it reimplements MFDs?
Also handing around a regmap might be nicer, compared to readl/writel.
Heiko
Powered by blists - more mailing lists