mbox series

[V4,0/2] pwm: Add GPIO PWM driver

Message ID 20240204220851.4783-1-wahrenst@gmx.net
Headers show
Series pwm: Add GPIO PWM driver | expand

Message

Stefan Wahren Feb. 4, 2024, 10:08 p.m. UTC
Add a software PWM which toggles a GPIO from a high-resolution timer.

Recent discussions in the Raspberry Pi community revealt that a lot
of users still use MMIO userspace tools for GPIO access. One argument
for this approach is the lack of a GPIO PWM kernel driver. So this
series tries to fill this gap.

This continues the work of Vincent Whitchurch [1], which is easier
to read and more consequent by rejecting sleeping GPIOs than Nicola's
approach [2].

The work has been tested on a Raspberry Pi 3 B+ and a cheap logic
analyzer.

V4:
 - address DT bindings comments from Conor Dooley
 - drop unnecessary MODULE_ALIAS() as suggested by Krzysztof Kozlowski
 - add range checks to apply which consider the hrtimer resolution
   (idea comes from Sean Young)
 - mark driver as atomic as suggested by Sean Young

V3:
 - rebase on top of v6.8-pwm-next
 - cherry-pick improvements from Nicola's series
 - try to address Uwe's, Linus' and Andy's comments
 - try to avoid GPIO glitches during probe
 - fix pwm_gpio_remove()
 - some code clean up's and comments

V2:
 - Rename gpio to gpios in binding
 - Calculate next expiry from expected current expiry rather than "now"
 - Only change configuration after current period ends
 - Implement get_state()
 - Add error message for probe failures
 - Stop PWM before unregister

[1] - https://lore.kernel.org/all/20200915135445.al75xmjxudj2rgcp@axis.com/T/
[2] - https://lore.kernel.org/all/20201205214353.xapax46tt5snzd2v@einstein.dilieto.eu/

Nicola Di Lieto (1):
  dt-bindings: pwm: Add pwm-gpio

Vincent Whitchurch (1):
  pwm: Add GPIO PWM driver

 .../devicetree/bindings/pwm/pwm-gpio.yaml     |  42 ++++
 drivers/pwm/Kconfig                           |  11 +
 drivers/pwm/Makefile                          |   1 +
 drivers/pwm/pwm-gpio.c                        | 228 ++++++++++++++++++
 4 files changed, 282 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-gpio.yaml
 create mode 100644 drivers/pwm/pwm-gpio.c

--
2.34.1

Comments

Dhruva Gole Feb. 5, 2024, 5:55 a.m. UTC | #1
Hi,

On Feb 04, 2024 at 23:08:49 +0100, Stefan Wahren wrote:
> Add a software PWM which toggles a GPIO from a high-resolution timer.
> 
> Recent discussions in the Raspberry Pi community revealt that a lot
> of users still use MMIO userspace tools for GPIO access. One argument
> for this approach is the lack of a GPIO PWM kernel driver. So this
> series tries to fill this gap.
> 
> This continues the work of Vincent Whitchurch [1], which is easier
> to read and more consequent by rejecting sleeping GPIOs than Nicola's
> approach [2].
> 
> The work has been tested on a Raspberry Pi 3 B+ and a cheap logic
> analyzer.

I recently came across this series and I have to say that it will sure be
a nice to have feature to be able to use any GPIO as a PWM.

However, just a minor suggestion is that we should make sure it's well
documented how to actually use this. It would be much appreciated if you
could include some basic documentation of a few sysfs commands or any
userspace library that you used to test what you've mentioned above.

Maybe add another patch for this page?
https://docs.kernel.org/driver-api/pwm.html#using-pwms-with-the-sysfs-interface

This will ensure people know about this feature and will actually be
able to use it.
Stefan Wahren Feb. 5, 2024, 7:08 a.m. UTC | #2
Hi Dhruva,

Am 05.02.24 um 06:55 schrieb Dhruva Gole:
> Hi,
>
> On Feb 04, 2024 at 23:08:49 +0100, Stefan Wahren wrote:
>> Add a software PWM which toggles a GPIO from a high-resolution timer.
>>
>> Recent discussions in the Raspberry Pi community revealt that a lot
>> of users still use MMIO userspace tools for GPIO access. One argument
>> for this approach is the lack of a GPIO PWM kernel driver. So this
>> series tries to fill this gap.
>>
>> This continues the work of Vincent Whitchurch [1], which is easier
>> to read and more consequent by rejecting sleeping GPIOs than Nicola's
>> approach [2].
>>
>> The work has been tested on a Raspberry Pi 3 B+ and a cheap logic
>> analyzer.
> I recently came across this series and I have to say that it will sure be
> a nice to have feature to be able to use any GPIO as a PWM.
>
> However, just a minor suggestion is that we should make sure it's well
> documented how to actually use this. It would be much appreciated if you
> could include some basic documentation of a few sysfs commands or any
> userspace library that you used to test what you've mentioned above.
i used the PWM sysfs for testing and this PWM driver doesn't change
anything on this well known interface.

Sorry, i don't understand what needs to be documented additionally?
>
> Maybe add another patch for this page?
> https://docs.kernel.org/driver-api/pwm.html#using-pwms-with-the-sysfs-interface
>
> This will ensure people know about this feature and will actually be
> able to use it.
>
Phil Howard Feb. 5, 2024, 1:06 p.m. UTC | #3
On Sun, 4 Feb 2024 at 22:09, Stefan Wahren <wahrenst@gmx.net> wrote:
>
> Add a software PWM which toggles a GPIO from a high-resolution timer.
>
> Recent discussions in the Raspberry Pi community revealt that a lot
> of users still use MMIO userspace tools for GPIO access. One argument
> for this approach is the lack of a GPIO PWM kernel driver. So this
> series tries to fill this gap.
>
> This continues the work of Vincent Whitchurch [1], which is easier
> to read and more consequent by rejecting sleeping GPIOs than Nicola's
> approach [2].
>
> The work has been tested on a Raspberry Pi 3 B+ and a cheap logic
> analyzer.

Tested on a Pi 5 with a Rigol scope. I have not done any comparative
testing to the contemporary methods of GPIO on a Pi (they're probably
not great) but it looks good at a glance.

There is jitter, as you might expect, though I would expect this to be much
better than the userspace soft PWM we're used to.

Mostly for Pi users who happen to be watching this unfold-

PWM on the Pi 5 is achieved via the PCIe bus to the RP1 peripheral and
IO controller on a Pi 5 so it's possible to saturate the PCIe bus and have
A Bad Day. I think ~200KHz is about the practical limit here, if I try and push
to 400KHz things start to get dicy. The faster you go, the more proportional
impact jitter will have on the resulting signal.

My optimistic first try in the MHz range booted me off SSH and required a
power cycle so I'm not even sure what went wrong. Less of an issue for
on-chip GPIO controllers ala <= Pi 4.

Here's my very naive overlay -

// Definitions for w1-gpio module (without external pullup)
/dts-v1/;
/plugin/;

/ {
    compatible = "brcm,bcm2835";
    fragment@0 {
        target-path = "/";
        __overlay__ {
            pwm_gpio: pwm_gpio@0 {
                compatible = "pwm-gpio";
                pinctrl-names = "default";
                pinctrl-0 = <&pwm_gpio_pins>;
                gpios = <&gpio 4 0>;
                status = "okay";
            };
        };
    };

    fragment@1 {
        target = <&gpio>;
        __overlay__ {
            pwm_gpio_pins: pwm_gpio_pins@0 {
                brcm,pins = <4>;
                brcm,function = <1>; // out
                brcm,pull = <0>; // off
            };
        };
    };
};

>
> V4:
>  - address DT bindings comments from Conor Dooley
>  - drop unnecessary MODULE_ALIAS() as suggested by Krzysztof Kozlowski
>  - add range checks to apply which consider the hrtimer resolution
>    (idea comes from Sean Young)
>  - mark driver as atomic as suggested by Sean Young
>
> V3:
>  - rebase on top of v6.8-pwm-next
>  - cherry-pick improvements from Nicola's series
>  - try to address Uwe's, Linus' and Andy's comments
>  - try to avoid GPIO glitches during probe
>  - fix pwm_gpio_remove()
>  - some code clean up's and comments
>
> V2:
>  - Rename gpio to gpios in binding
>  - Calculate next expiry from expected current expiry rather than "now"
>  - Only change configuration after current period ends
>  - Implement get_state()
>  - Add error message for probe failures
>  - Stop PWM before unregister
>
> [1] - https://lore.kernel.org/all/20200915135445.al75xmjxudj2rgcp@axis.com/T/
> [2] - https://lore.kernel.org/all/20201205214353.xapax46tt5snzd2v@einstein.dilieto.eu/
>
> Nicola Di Lieto (1):
>   dt-bindings: pwm: Add pwm-gpio
>
> Vincent Whitchurch (1):
>   pwm: Add GPIO PWM driver
>
>  .../devicetree/bindings/pwm/pwm-gpio.yaml     |  42 ++++
>  drivers/pwm/Kconfig                           |  11 +
>  drivers/pwm/Makefile                          |   1 +
>  drivers/pwm/pwm-gpio.c                        | 228 ++++++++++++++++++
>  4 files changed, 282 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-gpio.yaml
>  create mode 100644 drivers/pwm/pwm-gpio.c
>
> --
> 2.34.1
>
Linus Walleij May 27, 2024, 8:22 a.m. UTC | #4
On Sun, Feb 4, 2024 at 11:09 PM Stefan Wahren <wahrenst@gmx.net> wrote:

> Add a software PWM which toggles a GPIO from a high-resolution timer.

Is work still ongoing on this patch series?

I would use the patches and I like them a lot so I'm happy to help if need be.

Yours,
Linus Walleij
Stefan Wahren May 27, 2024, 8:44 a.m. UTC | #5
Hi Linus,

Am 27.05.24 um 10:22 schrieb Linus Walleij:
> On Sun, Feb 4, 2024 at 11:09 PM Stefan Wahren <wahrenst@gmx.net> wrote:
>
>> Add a software PWM which toggles a GPIO from a high-resolution timer.
> Is work still ongoing on this patch series?
i addressed most of the comments of V4 except of the possible interrupt
storm in case the period/duty cycle is set too short (comment by Sean
Young). In the last time i prioritized other things and tbh it's
unlikely i find enough time to finish this within 6.10 cycle.
> I would use the patches and I like them a lot so I'm happy to help if need be.
I could rebase my latest work on 6.10-rc1 and send it out as V5. I would
be happy if you want to continue on that driver.

Thanks
>
> Yours,
> Linus Walleij
Linus Walleij May 27, 2024, 9:56 a.m. UTC | #6
On Mon, May 27, 2024 at 10:44 AM Stefan Wahren <wahrenst@gmx.net> wrote:

> I could rebase my latest work on 6.10-rc1 and send it out as V5. I would
> be happy if you want to continue on that driver.

I could probably do that! Let's see v5 and take it from there.

Yours,
Linus Walleij