From: William Breathitt Gray <wbg@kernel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Sebastian Reichel" <sebastian.reichel@collabora.com>,
"Kever Yang" <kever.yang@rock-chips.com>,
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>
Subject: Re: [PATCH 6/7] counter: Add rockchip-pwm-capture driver
Date: Wed, 7 May 2025 17:47:18 +0900 [thread overview]
Message-ID: <aBseFo-EC-PzxiqM@ishi> (raw)
In-Reply-To: <20250408-rk3576-pwm-v1-6-a49286c2ca8e@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]
On Tue, Apr 08, 2025 at 02:32:18PM +0200, Nicolas Frattaroli wrote:
> Among many other things, Rockchip's new PWMv4 IP in the RK3576 supports
> PWM capture functionality.
>
> Add a basic driver for this that works to capture period and duty cycle
> values and return them as nanoseconds to the user. It's quite basic, but
> works well enough to demonstrate the device function exclusion stuff
> that mfpwm does, in order to eventually support all the functions of
> this device in drivers within their appropriate subsystems, without them
> interfering with each other.
>
> Once enabled, the counter driver waits for enough high-to-low and
> low-to-high interrupt signals to arrive, and then writes the cycle count
> register values into some atomic members of the driver instance's state
> struct. The read callback can then do the conversion from cycle count to
> the more useful period and duty cycle nanosecond values, which require
> knowledge of the clock rate, which requires a call that the interrupt
> handler cannot make itself because said call may sleep.
>
> To detect the condition of a PWM signal disappearing, i.e. turning off,
> we modify the delay value of a delayed worker whose job it is to simply
> set those atomic members to zero. Should the "timeout" so to speak be
> reached, we assume the PWM signal is off. This isn't perfect; it
> obviously introduces a latency between it being off and the counter
> reporting it as such. Additionally, periods longer than the timeout
> value will cause the count to "flicker" between the correct period and
> duty cycle values, and zero. This is because there doesn't appear to be
> a way to reset the hardware's internal counters, even when writing to
> the registers.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Hi Nicolas,
I just want to give you a heads-up that I'm looking over this but it's
going to take me a couple more weeks or so; this hardware is a little
weird so I want to properly grok it before I Ack such a driver. In
particular, I'm not sure yet that the counter subsystem is necessarily
the right place for this functionality if you're ultimately after values
in units of time (sounds more like a clk framework feature) -- but we'll
determine so together.
That being said, please continue on to a version 2 of this patchset if
you have other changes ready -- I don't want the counter driver
bottlenecking the development of the rest of this series when progress
can be made independent of it.
Thanks,
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: William Breathitt Gray <wbg@kernel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
"Sebastian Reichel" <sebastian.reichel@collabora.com>,
"Kever Yang" <kever.yang@rock-chips.com>,
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>
Subject: Re: [PATCH 6/7] counter: Add rockchip-pwm-capture driver
Date: Wed, 7 May 2025 17:47:18 +0900 [thread overview]
Message-ID: <aBseFo-EC-PzxiqM@ishi> (raw)
In-Reply-To: <20250408-rk3576-pwm-v1-6-a49286c2ca8e@collabora.com>
[-- Attachment #1.1: Type: text/plain, Size: 2592 bytes --]
On Tue, Apr 08, 2025 at 02:32:18PM +0200, Nicolas Frattaroli wrote:
> Among many other things, Rockchip's new PWMv4 IP in the RK3576 supports
> PWM capture functionality.
>
> Add a basic driver for this that works to capture period and duty cycle
> values and return them as nanoseconds to the user. It's quite basic, but
> works well enough to demonstrate the device function exclusion stuff
> that mfpwm does, in order to eventually support all the functions of
> this device in drivers within their appropriate subsystems, without them
> interfering with each other.
>
> Once enabled, the counter driver waits for enough high-to-low and
> low-to-high interrupt signals to arrive, and then writes the cycle count
> register values into some atomic members of the driver instance's state
> struct. The read callback can then do the conversion from cycle count to
> the more useful period and duty cycle nanosecond values, which require
> knowledge of the clock rate, which requires a call that the interrupt
> handler cannot make itself because said call may sleep.
>
> To detect the condition of a PWM signal disappearing, i.e. turning off,
> we modify the delay value of a delayed worker whose job it is to simply
> set those atomic members to zero. Should the "timeout" so to speak be
> reached, we assume the PWM signal is off. This isn't perfect; it
> obviously introduces a latency between it being off and the counter
> reporting it as such. Additionally, periods longer than the timeout
> value will cause the count to "flicker" between the correct period and
> duty cycle values, and zero. This is because there doesn't appear to be
> a way to reset the hardware's internal counters, even when writing to
> the registers.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Hi Nicolas,
I just want to give you a heads-up that I'm looking over this but it's
going to take me a couple more weeks or so; this hardware is a little
weird so I want to properly grok it before I Ack such a driver. In
particular, I'm not sure yet that the counter subsystem is necessarily
the right place for this functionality if you're ultimately after values
in units of time (sounds more like a clk framework feature) -- but we'll
determine so together.
That being said, please continue on to a version 2 of this patchset if
you have other changes ready -- I don't want the counter driver
bottlenecking the development of the rest of this series when progress
can be made independent of it.
Thanks,
William Breathitt Gray
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-05-07 9:37 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 12:32 [PATCH 0/7] Add Rockchip RK3576 PWM Support Through MFPWM Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-04-08 12:32 ` [PATCH 1/7] dt-bindings: pinctrl: rockchip: increase max amount of device functions Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-04-08 16:08 ` Conor Dooley
2025-04-08 16:08 ` Conor Dooley
2025-04-08 17:27 ` Rob Herring
2025-04-08 17:27 ` Rob Herring
2025-05-31 12:59 ` Heiko Stübner
2025-05-31 12:59 ` Heiko Stübner
2025-04-08 12:32 ` [PATCH 2/7] dt-bindings: pwm: Add a new binding for rockchip,rk3576-pwm Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-04-08 16:07 ` Conor Dooley
2025-04-08 16:07 ` Conor Dooley
2025-04-08 12:32 ` [PATCH 3/7] soc: rockchip: add utils header for things shared across drivers Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-05-31 13:26 ` Heiko Stübner
2025-05-31 13:26 ` Heiko Stübner
2025-04-08 12:32 ` [PATCH 4/7] soc: rockchip: add mfpwm driver Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-04-08 20:03 ` Heiko Stübner
2025-04-08 20:03 ` Heiko Stübner
2025-04-09 13:01 ` Nicolas Frattaroli
2025-04-09 13:01 ` Nicolas Frattaroli
2025-05-08 7:13 ` Damon Ding
2025-05-08 7:13 ` Damon Ding
2025-05-31 21:48 ` Heiko Stübner
2025-05-31 21:48 ` Heiko Stübner
2025-06-02 12:15 ` Nicolas Frattaroli
2025-06-02 12:15 ` Nicolas Frattaroli
2025-06-02 13:14 ` Heiko Stübner
2025-06-02 13:14 ` Heiko Stübner
2025-04-08 12:32 ` [PATCH 5/7] pwm: Add rockchip PWMv4 driver Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-05-13 17:26 ` Uwe Kleine-König
2025-05-13 17:26 ` Uwe Kleine-König
2025-05-22 13:02 ` Nicolas Frattaroli
2025-05-22 13:02 ` Nicolas Frattaroli
2025-05-23 15:02 ` Uwe Kleine-König
2025-05-23 15:02 ` Uwe Kleine-König
2025-05-26 9:30 ` Nicolas Frattaroli
2025-05-26 9:30 ` Nicolas Frattaroli
2025-04-08 12:32 ` [PATCH 6/7] counter: Add rockchip-pwm-capture driver Nicolas Frattaroli
2025-04-08 12:32 ` Nicolas Frattaroli
2025-05-07 8:47 ` William Breathitt Gray [this message]
2025-05-07 8:47 ` William Breathitt Gray
2025-04-08 12:32 ` [PATCH 7/7] arm64: dts: rockchip: add PWM nodes to RK3576 SoC dtsi Nicolas Frattaroli
2025-04-08 12:32 ` 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=aBseFo-EC-PzxiqM@ishi \
--to=wbg@kernel.org \
--cc=conor+dt@kernel.org \
--cc=detlev.casanova@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=kever.yang@rock-chips.com \
--cc=krzk+dt@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=nicolas.frattaroli@collabora.com \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=ukleinek@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.