From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: "Uwe Kleine-König" <ukleinek@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>, "Lee Jones" <lee@kernel.org>,
"William Breathitt Gray" <wbg@kernel.org>,
"Johan Jonker" <jbx6244@yandex.com>
Cc: kernel@collabora.com, Jonas Karlman <jonas@kwiboo.se>,
Alexey Charkov <alchark@gmail.com>,
linux-rockchip@lists.infradead.org, linux-pwm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v3 2/5] mfd: Add Rockchip mfpwm driver
Date: Fri, 31 Oct 2025 13:20:37 +0100 [thread overview]
Message-ID: <3598089.ElGaqSPkdT@workhorse> (raw)
In-Reply-To: <16341fe2-7d2b-45a6-a861-93950c1bbd1f@yandex.com>
On Tuesday, 28 October 2025 19:52:53 Central European Standard Time Johan Jonker wrote:
>
> On 10/27/25 18:11, Nicolas Frattaroli wrote:
> > 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 MFD core 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 MFD cell 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>
> > ---
> > MAINTAINERS | 2 +
> > drivers/mfd/Kconfig | 15 ++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/rockchip-mfpwm.c | 340 +++++++++++++++++++++++++++
> > include/linux/mfd/rockchip-mfpwm.h | 454 +++++++++++++++++++++++++++++++++++++
> > 5 files changed, 812 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index baecabab35a2..8f3235ba825e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22372,6 +22372,8 @@ L: linux-rockchip@lists.infradead.org
> > L: linux-pwm@vger.kernel.org
> > S: Maintained
>
> > F: Documentation/devicetree/bindings/pwm/rockchip,rk3576-pwm.yaml
>
> A question not so much for Nicolas specific:
> The yaml documents already have a 'maintainers' entry.
> However MAINTAINERS is full yaml entries.
> Could someone explain why we still need dual registration?
>
> maintainers:
> - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
> > +F: drivers/soc/rockchip/mfpwm.c
> > +F: include/soc/rockchip/mfpwm.h
>
> different file name and location?
>
> drivers/mfd/rockchip-mfpwm.c | 340 +++++++++++++++++++++++++++
> include/linux/mfd/rockchip-mfpwm.h | 454 +++++++++++++++++++++++++++++++++++++
>
>
Yeah, I forgot to adjust this when moving this to being an MFD.
I'll fix it in v4.
> > [... snip ...]
> > diff --git a/drivers/mfd/rockchip-mfpwm.c b/drivers/mfd/rockchip-mfpwm.c
> > new file mode 100644
> > index 000000000000..08c2d8da41b7
> > --- /dev/null
> > +++ b/drivers/mfd/rockchip-mfpwm.c
> > [... snip ...]
> > +
> > +static int mfpwm_register_subdevs(struct rockchip_mfpwm *mfpwm)
> > +{
> > + int ret;
> > +
>
> > + ret = mfpwm_register_subdev(mfpwm, "pwm-rockchip-v4");
>
> Not sure who came up with this name?
I did.
> In case we need to filter wouldn't be easier to order it just like the bindings: manufacture '-' function
It's based on the filename of the pwm output driver. pwm-rockchip.c
is already taken by v1 to v3 hardware. Apparently however, pwm
subsystem drivers then reverse the order in the driver name, so
`pwm-rockchip.c` registers a driver with the name `rockchip-pwm`.
So I'll rename my PWM output driver to `rockchip-pwm-v4`. The v4
stays, it refers to the hardware IP revision.
> > + if (ret)
> > + return ret;
> > +
> > + ret = mfpwm_register_subdev(mfpwm, "rockchip-pwm-capture");
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > [... snip ...]
Kind regards,
Nicolas Frattaroli
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: "Uwe Kleine-König" <ukleinek@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>, "Lee Jones" <lee@kernel.org>,
"William Breathitt Gray" <wbg@kernel.org>,
"Johan Jonker" <jbx6244@yandex.com>
Cc: kernel@collabora.com, Jonas Karlman <jonas@kwiboo.se>,
Alexey Charkov <alchark@gmail.com>,
linux-rockchip@lists.infradead.org, linux-pwm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v3 2/5] mfd: Add Rockchip mfpwm driver
Date: Fri, 31 Oct 2025 13:20:37 +0100 [thread overview]
Message-ID: <3598089.ElGaqSPkdT@workhorse> (raw)
In-Reply-To: <16341fe2-7d2b-45a6-a861-93950c1bbd1f@yandex.com>
On Tuesday, 28 October 2025 19:52:53 Central European Standard Time Johan Jonker wrote:
>
> On 10/27/25 18:11, Nicolas Frattaroli wrote:
> > 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 MFD core 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 MFD cell 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>
> > ---
> > MAINTAINERS | 2 +
> > drivers/mfd/Kconfig | 15 ++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/rockchip-mfpwm.c | 340 +++++++++++++++++++++++++++
> > include/linux/mfd/rockchip-mfpwm.h | 454 +++++++++++++++++++++++++++++++++++++
> > 5 files changed, 812 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index baecabab35a2..8f3235ba825e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22372,6 +22372,8 @@ L: linux-rockchip@lists.infradead.org
> > L: linux-pwm@vger.kernel.org
> > S: Maintained
>
> > F: Documentation/devicetree/bindings/pwm/rockchip,rk3576-pwm.yaml
>
> A question not so much for Nicolas specific:
> The yaml documents already have a 'maintainers' entry.
> However MAINTAINERS is full yaml entries.
> Could someone explain why we still need dual registration?
>
> maintainers:
> - Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
> > +F: drivers/soc/rockchip/mfpwm.c
> > +F: include/soc/rockchip/mfpwm.h
>
> different file name and location?
>
> drivers/mfd/rockchip-mfpwm.c | 340 +++++++++++++++++++++++++++
> include/linux/mfd/rockchip-mfpwm.h | 454 +++++++++++++++++++++++++++++++++++++
>
>
Yeah, I forgot to adjust this when moving this to being an MFD.
I'll fix it in v4.
> > [... snip ...]
> > diff --git a/drivers/mfd/rockchip-mfpwm.c b/drivers/mfd/rockchip-mfpwm.c
> > new file mode 100644
> > index 000000000000..08c2d8da41b7
> > --- /dev/null
> > +++ b/drivers/mfd/rockchip-mfpwm.c
> > [... snip ...]
> > +
> > +static int mfpwm_register_subdevs(struct rockchip_mfpwm *mfpwm)
> > +{
> > + int ret;
> > +
>
> > + ret = mfpwm_register_subdev(mfpwm, "pwm-rockchip-v4");
>
> Not sure who came up with this name?
I did.
> In case we need to filter wouldn't be easier to order it just like the bindings: manufacture '-' function
It's based on the filename of the pwm output driver. pwm-rockchip.c
is already taken by v1 to v3 hardware. Apparently however, pwm
subsystem drivers then reverse the order in the driver name, so
`pwm-rockchip.c` registers a driver with the name `rockchip-pwm`.
So I'll rename my PWM output driver to `rockchip-pwm-v4`. The v4
stays, it refers to the hardware IP revision.
> > + if (ret)
> > + return ret;
> > +
> > + ret = mfpwm_register_subdev(mfpwm, "rockchip-pwm-capture");
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > [... snip ...]
Kind regards,
Nicolas Frattaroli
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-10-31 12:21 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 17:11 [PATCH v3 0/5] Add Rockchip RK3576 PWM Support Through MFPWM Nicolas Frattaroli
2025-10-27 17:11 ` Nicolas Frattaroli
2025-10-27 17:11 ` [PATCH v3 1/5] dt-bindings: pwm: Add a new binding for rockchip,rk3576-pwm Nicolas Frattaroli
2025-10-27 17:11 ` Nicolas Frattaroli
2025-10-28 3:06 ` Damon Ding
2025-10-28 3:06 ` Damon Ding
2025-10-28 8:50 ` Conor Dooley
2025-10-28 8:50 ` Conor Dooley
2025-10-28 10:42 ` Damon Ding
2025-10-28 10:42 ` Damon Ding
2025-10-27 17:11 ` [PATCH v3 2/5] mfd: Add Rockchip mfpwm driver Nicolas Frattaroli
2025-10-27 17:11 ` Nicolas Frattaroli
2025-10-28 18:52 ` Johan Jonker
2025-10-28 18:52 ` Johan Jonker
2025-10-31 12:20 ` Nicolas Frattaroli [this message]
2025-10-31 12:20 ` Nicolas Frattaroli
2025-11-03 15:25 ` Lee Jones
2025-11-03 15:25 ` Lee Jones
2025-10-27 17:11 ` [PATCH v3 3/5] pwm: Add rockchip PWMv4 driver Nicolas Frattaroli
2025-10-27 17:11 ` Nicolas Frattaroli
2025-10-28 8:16 ` Damon Ding
2025-10-28 8:16 ` Damon Ding
2025-11-14 9:51 ` Uwe Kleine-König
2025-11-14 9:51 ` Uwe Kleine-König
2025-11-14 10:13 ` Nicolas Frattaroli
2025-11-14 10:13 ` Nicolas Frattaroli
2025-11-14 10:41 ` Uwe Kleine-König
2025-11-14 10:41 ` Uwe Kleine-König
2025-10-27 17:11 ` [PATCH v3 4/5] counter: Add rockchip-pwm-capture driver Nicolas Frattaroli
2025-10-27 17:11 ` Nicolas Frattaroli
2025-10-28 11:05 ` Damon Ding
2025-10-28 11:05 ` Damon Ding
2025-12-06 9:34 ` William Breathitt Gray
2025-12-06 9:34 ` William Breathitt Gray
2026-04-20 12:02 ` Nicolas Frattaroli
2026-04-20 12:02 ` Nicolas Frattaroli
2025-10-27 17:12 ` [PATCH v3 5/5] arm64: dts: rockchip: add PWM nodes to RK3576 SoC dtsi Nicolas Frattaroli
2025-10-27 17:12 ` 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=3598089.ElGaqSPkdT@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=alchark@gmail.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jbx6244@yandex.com \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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=robh@kernel.org \
--cc=ukleinek@kernel.org \
--cc=wbg@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.