pwm on 5.10.73-bone56, can not find the filesystem version

I had a system running on beaglebone 4.14, where I created for pwm interfaces via
config-pin p8.34 pwm #PWM1B
config-pin p8.36 pwm #PWM1A
config-pin p8.45 pwm #PWM2A
config-pin p8.46 pwm #PWM2B
I would find the devices under
/sys/class/pwm/pwmchip3/pwm3:0
/sys/class/pwm/pwmchip3/pwm3:1
and
/sys/class/pwm/pwmchip6/pwm6:0.
/sys/class/pwm/pwmchip6/pwm6:1.

Now I do not find these things, while config-pins from bbb-pin-utils shows they are there:

P8.45 / hdmi / sysboot 0 40 fast rx down 3 pwm 2 out A ocp/P8_45_pinmux (pinmux_P8_45_pwm_pin)
P8.46 / hdmi / sysboot 1 41 fast rx down 3 pwm 2 out B ocp/P8_46_pinmux (pinmux_P8_46_pwm_pin)
P8.36 / hdmi / sysboot 10 50 fast rx down 2 pwm 1 out A ocp/P8_36_pinmux (pinmux_P8_36_pwm_pin)
P8.34 / hdmi / sysboot 11 51 fast rx down 2 pwm 1 out B ocp/P8_34_pinmux (pinmux_P8_34_pwm_pin)

How do I work with these pwm settings via the old way like:

echo -n “1” > /sys/class/pwm/pwmchip3/pwm-3:0/enable
echo 5000000 > /sys/class/pwm/pwmchip3/pwm-3:0/period
echo 4000000 > /sys/class/pwm/pwmchip3/pwm-3:0/duty_cycle
echo 3000000 > /sys/class/pwm/pwmchip3/pwm-3:0/duty_cycle

Kind Regards
Johan

This was an abi change after 5.4.x~ish…

They are still under /sys/class/pwm/* but a new name…

Regards,

And the new name is ???

I had a look at Pulse Width Modulation (PWM) interface — The Linux Kernel documentation, to see if I could find something there, but looking there creates more confusion: /sys/class/pwm/pwmchip3 used to have 2 channels, if I ask the number of pwm channels via cat /sys/class/pwm/pwmchip3/npwm , I only get one channel.

(I’v been scratching some of my now scarcer getting hairs where to look)

Kind Regards,
Johan Henselmans

In order to save your hairs, perhaps you’ll have to look at libpruio. PWM since version 0.2, no major changes since Oct 2014 (just further lines added). Currently 20 PWM output pins/lines on BBB, and you can synchonize the PWM_SS if need be.

Thanks for the hair.

I actually found out that the numbering somehow changed:
It used to be:

config-pin p8.34 pwm #PWM1B (chip3 1)
config-pin p8.36 pwm #PWM1A (chip3 0)
config-pin p8.45 pwm #PWM2A (chip6 0)
config-pin p8.46 pwm #PWM2B (chip6 1)

But now it is:

 config-pin p8.34 pwm #PWM1B (chip4 1)
 config-pin p8.36 pwm #PWM1A (chip4 0)
 config-pin p8.45 pwm #PWM2A (chip7 0)
 config-pin p8.46 pwm #PWM2B (chip7 1)

So now this works:

echo 0 > /sys/class/pwm/pwmchip4/export
echo 1 > /sys/class/pwm/pwmchip4/export 
echo 0 > /sys/class/pwm/pwmchip7/export 
echo 1 > /sys/class/pwm/pwmchip7/export

echo 5000000 > /sys/class/pwm/pwmchip4/pwm-4\:0/period
echo 5000000 > /sys/class/pwm/pwmchip4/pwm-4\:0/duty_cycle
echo 5000000 > /sys/class/pwm/pwmchip4/pwm-4\:1/period
echo 5000000 > /sys/class/pwm/pwmchip4/pwm-4\:1/duty_cycle
echo 5000000 > /sys/class/pwm/pwmchip7/pwm-7\:0/period
echo 5000000 > /sys/class/pwm/pwmchip7/pwm-7\:0/duty_cycle
echo 5000000 > /sys/class/pwm/pwmchip7/pwm-7\:1/period
echo 5000000 > /sys/class/pwm/pwmchip7/pwm-7\:1/duty_cycle
echo -n "0" > /sys/class/pwm/pwmchip4/pwm-4\:0/enable
echo -n "0" > /sys/class/pwm/pwmchip4/pwm-4\:1/enable
echo -n "0" > /sys/class/pwm/pwmchip7/pwm-7\:0/enable
echo -n "0" > /sys/class/pwm/pwmchip7/pwm-7\:1/enable
sleep 1
echo -n "1" > /sys/class/pwm/pwmchip4/pwm-4\:0/enable
echo -n "1" > /sys/class/pwm/pwmchip4/pwm-4\:1/enable
echo -n "1" > /sys/class/pwm/pwmchip7/pwm-7\:0/enable
echo -n "1" > /sys/class/pwm/pwmchip7/pwm-7\:1/enable
sleep 1
echo 2000000 > /sys/class/pwm/pwmchip4/pwm-4\:0/duty_cycle
echo 2000000 > /sys/class/pwm/pwmchip4/pwm-4\:1/duty_cycle
echo 2000000 > /sys/class/pwm/pwmchip7/pwm-7\:0/duty_cycle
echo 2000000 > /sys/class/pwm/pwmchip7/pwm-7\:1/duty_cycle

But I wil definitely have a look at PRUI, sometime in the future.

Duh, found that ti kernels use /sys/class/pwm/pcwmchip4/pwm4:0 and bone kernels it is /sys/class/pwm/pwmchip4/pwm0.

OK, 1 bug down, still 4 to go.

Regards,
Johan Henselmans

Perhaps you want to reorder your priorities. libpruio doesn’t use sysfs, except for one single call in the CTOR (in order to respect existing CPU ball claims). And even that single sysfs call causes problems on different kernel versions (covered by libpruio, the user doesn’t see them).