From: "Heiko Stübner" <heiko@sntech.de>
To: "Linus Walleij" <linus.walleij@linaro.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"William Breathitt Gray" <wbg@kernel.org>,
"Sebastian Reichel" <sebastian.reichel@collabora.com>,
"Kever Yang" <kever.yang@rock-chips.com>,
"Yury Norov" <yury.norov@gmail.com>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dave Ertman <david.m.ertman@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Leon Romanovsky <leon@kernel.org>, Lee Jones <lee@kernel.org>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pwm@vger.kernel.org, linux-iio@vger.kernel.org,
kernel@collabora.com, Jonas Karlman <jonas@kwiboo.se>,
Detlev Casanova <detlev.casanova@collabora.com>,
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Subject: Re: [PATCH v2 4/7] soc: rockchip: add mfpwm driver
Date: Wed, 09 Jul 2025 09:22:57 +0200 [thread overview]
Message-ID: <8203440.zQ0Gbyo6oJ@diego> (raw)
In-Reply-To: <20250602-rk3576-pwm-v2-4-a6434b0ce60c@collabora.com>
Hi Nicolas,
Am Montag, 2. Juni 2025, 18:19:15 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@collabora.com>
> ---
> +/**
> + * mfpwm_register_subdev - register a single mfpwm_func
> + * @mfpwm: pointer to the parent &struct rockchip_mfpwm
> + * @target: pointer to where the &struct platform_device pointer should be
> + * stored, usually a member of @mfpwm
> + * @name: sub-device name string
> + *
> + * Allocate a single &struct mfpwm_func, fill its members with appropriate data,
> + * and register a new platform device, saving its pointer to @target. The
> + * allocation is devres tracked, so will be automatically freed on mfpwm remove.
> + *
> + * Returns: 0 on success, negative errno on error
> + */
> +static int mfpwm_register_subdev(struct rockchip_mfpwm *mfpwm,
> + struct platform_device **target,
> + const char *name)
> +{
> + struct rockchip_mfpwm_func *func;
> + struct platform_device *child;
> +
> + func = devm_kzalloc(&mfpwm->pdev->dev, sizeof(*func), GFP_KERNEL);
> + if (IS_ERR(func))
> + return PTR_ERR(func);
> + func->irq = mfpwm->irq;
> + func->parent = mfpwm;
> + func->id = atomic_inc_return(&subdev_id);
> + func->base = mfpwm->base;
> + func->core = mfpwm->chosen_clk;
> + child = platform_device_register_data(&mfpwm->pdev->dev, name, func->id,
> + func, sizeof(*func));
> +
> + if (IS_ERR(child))
> + return PTR_ERR(child);
> +
> + *target = child;
> +
> + return 0;
> +}
> +
> +static int mfpwm_register_subdevs(struct rockchip_mfpwm *mfpwm)
> +{
> + int ret;
> +
> + ret = mfpwm_register_subdev(mfpwm, &mfpwm->pwm_dev, "pwm-rockchip-v4");
> + if (ret)
> + return ret;
> +
> + ret = mfpwm_register_subdev(mfpwm, &mfpwm->counter_dev,
> + "rockchip-pwm-capture");
> + if (ret)
> + goto err_unreg_pwm_dev;
> +
> + return 0;
> +
> +err_unreg_pwm_dev:
> + platform_device_unregister(mfpwm->pwm_dev);
> +
> + return ret;
> +}
I still had this lingering feeling that this _is_ a MFD just with added
sprinkles, so asked Lee on IRC about it:
<lag> Looks like an MFD to me
<lag> Yes, you can use an MFD core driver to control state / manage single-use resources
So, citing Jean Luc Picard, "Make it so" ... please :-)
Heiko
next prev parent reply other threads:[~2025-07-09 7:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-02 16:19 [PATCH v2 0/7] Add Rockchip RK3576 PWM Support Through MFPWM Nicolas Frattaroli
2025-06-02 16:19 ` [PATCH v2 1/7] dt-bindings: pinctrl: rockchip: increase max amount of device functions Nicolas Frattaroli
2025-06-05 13:29 ` Linus Walleij
2025-06-05 14:35 ` Nicolas Frattaroli
2025-06-10 12:33 ` Linus Walleij
2025-06-02 16:19 ` [PATCH v2 2/7] dt-bindings: pwm: Add a new binding for rockchip,rk3576-pwm Nicolas Frattaroli
2025-06-06 2:16 ` Rob Herring (Arm)
2025-06-02 16:19 ` [PATCH v2 3/7] bitfield: introduce HI16_WE bitfield prep macros Nicolas Frattaroli
2025-06-02 19:01 ` Heiko Stübner
2025-06-02 20:02 ` Yury Norov
2025-06-03 12:55 ` Nicolas Frattaroli
2025-06-03 16:21 ` Yury Norov
2025-06-02 16:19 ` [PATCH v2 4/7] soc: rockchip: add mfpwm driver Nicolas Frattaroli
2025-07-09 7:22 ` Heiko Stübner [this message]
2025-06-02 16:19 ` [PATCH v2 5/7] pwm: Add rockchip PWMv4 driver Nicolas Frattaroli
2025-06-23 8:44 ` Uwe Kleine-König
2025-06-02 16:19 ` [PATCH v2 6/7] counter: Add rockchip-pwm-capture driver Nicolas Frattaroli
2025-07-20 0:20 ` William Breathitt Gray
2025-08-25 9:11 ` Nicolas Frattaroli
2025-06-02 16:19 ` [PATCH v2 7/7] arm64: dts: rockchip: add PWM nodes to RK3576 SoC dtsi Nicolas Frattaroli
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=8203440.zQ0Gbyo6oJ@diego \
--to=heiko@sntech.de \
--cc=conor+dt@kernel.org \
--cc=david.m.ertman@intel.com \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=kever.yang@rock-chips.com \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=leon@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux@rasmusvillemoes.dk \
--cc=nicolas.frattaroli@collabora.com \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=ukleinek@kernel.org \
--cc=wbg@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;
as well as URLs for NNTP newsgroup(s).