So a few things to note about pwm behavior on the latest stretch image versus Jessie.
Obviously, Jessie by default runs an older kernel. 4.4.x versus 4.9.x.
First,
Jessie:
root@wgd:~# uname -r
4.4.68-ti-r111
root@wgd:~# lsmod |grep pwm
pwm_tiehrpwm
Stretch:
root@wgd:~# uname -r
4.9.50-ti-r61
root@wgd:~# lsmod |grep pwm /* No output */
Here, I’m thinking the PWM module is built into the kernel. Because I’m running the same custom overlay on both boards, and both have a populated sysfs entry for pwm. However there is a difference.
Jessie:
root@wgd:~# ls /sys/class/pwm/pwmchip0
device export npwm power pwm0 pwm1 subsystem uevent unexport
Stretch:
root@wgd:~# ls /sys/class/pwm/pwmchip0
device export npwm power pwm0 subsystem uevent unexport
Here, initially, there was no pwm0 substructure. This populated after I ran echo ‘0’ > /sys/class/pwm/pwmchip0/export as root. Further examination seems to indicate that pwm0 channel A is fully functional.
root@wgd:~# ls /sys/class/pwm/pwmchip0/pwm0/
capture duty_cycle enable period polarity power uevent
But I have not physically tested the hardware just yet.
So my questions are this. What’s the difference ? Does this have something to do with the module being built into the kernel. or is there some kind of overlay change I’m not currrently aware of ?
config-pin for my project here is not an option . . . And in fact, cape_universal is disabled via the uboot envrorinment file.
Everything else seems to be exactly the same as far as I can tell, but I have not poured over the whole system just yet. Seems to be pretty stable too, but I’ve only been running the latest console stretch image for a few days now.
Don't compare "pwmchipX's" directly, you need to dig into the symlink:
root@beaglebone:/sys/class/pwm# ls -lh
total 0
lrwxrwxrwx 1 root root 0 Oct 13 17:14 pwmchip0 ->
../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip0
lrwxrwxrwx 1 root root 0 Oct 13 17:14 pwmchip2 ->
../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip2
lrwxrwxrwx 1 root root 0 Oct 13 17:14 pwmchip3 ->
../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3
lrwxrwxrwx 1 root root 0 Oct 13 17:14 pwmchip5 ->
../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip5
lrwxrwxrwx 1 root root 0 Oct 13 17:14 pwmchip7 ->
../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7
https://github.com/RobertCNelson/bb.org-overlays/blob/master/examples/cape-unversal-pwm.txt#L3-L9
Regards,
Well there does seem to be a small difference between the two in the
subchannel directory too.
Jessie:
root@wgd:~# ls /sys/class/pwm/pwmchip0/pwm0/
duty_cycle enable period polarity power uevent
Stretch:
root@wgd:~# ls /sys/class/pwm/pwmchip0/pwm0/
capture duty_cycle enable period polarity power uevent
But I do not have a problem with that so much, as long as it doesnt
interfere with pwm functionality.
So I get what you're saying, and get what the link is stating as well.
However, I'm not seeing how the pwmchipX value is changing at all. More to
the point, I really do not care if the underlying path changes, so long as
I do not have to completely rewrite a library in order to use the sysfs pwm
objects. Moreover, what good is loading a uboot overlay, if that overlay
does not do what it is supposed to do ? It would be really nice to have
the pwm channels functioning before the OS is loaded.
*Jessie:*
root@wgd:~# ls -lh /sys/class/pwm
total 0
lrwxrwxrwx 1 root pwm 0 Sep 24 19:18 pwmchip0 ->
../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip0
lrwxrwxrwx 1 root pwm 0 Sep 24 19:18 pwmchip2 ->
../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2
lrwxrwxrwx 1 root pwm 0 Sep 24 19:18 pwmchip4 ->
../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4
*Stretch:*
root@wgd:~# ls -lh /sys/class/pwm
total 0
lrwxrwxrwx 1 root pwm 0 Sep 26 21:20 pwmchip0 ->
../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip0
lrwxrwxrwx 1 root pwm 0 Sep 26 21:20 pwmchip2 ->
../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2
lrwxrwxrwx 1 root pwm 0 Sep 26 21:20 pwmchip4 ->
../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4
Seriously, I can run a script at boot, then run all the echo's I need in
order to populate the entire pwm subsystem for each "duel channel" pwm chip
I need to use. But it was my hope I did not have to.
With all of that said, this structure is all I care about.
root@wgd:~# uname -r
4.4.68-ti-r111
root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
/sys/class/pwm/pwmchip0/:
npwm
pwm0
pwm1
/sys/class/pwm/pwmchip2/:
npwm
pwm0
pwm1
/sys/class/pwm/pwmchip4/:
npwm
pwm0
pwm1
I would like Stretch to be the same at boot, without the need to run a
script if possible. But it's not.
root@wgd:~# uname -r
4.9.50-ti-r61
root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
/sys/class/pwm/pwmchip0/:
npwm
pwm0
/sys/class/pwm/pwmchip2/:
npwm
/sys/class/pwm/pwmchip4/:
npwm
Did I miss something in what you were saying ?
Robert,
Ok I think I see what you mean now( fully ). With universal IO and the generic startup script enabled. I did see something similar to what you were saying. However, if one disables both universal IO, and the generic startup script, then writes their own custom overlay for all 3 of the PWM chips that are dual channel. You get a structure like this:
root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
/sys/class/pwm/pwmchip0/:
npwm
/sys/class/pwm/pwmchip2/:
npwm
/sys/class/pwm/pwmchip4/:
npwm
This is consistent across multiple images on the same board. In this case a 4G beaglebone black( rev C ). But at the same time as you can see from the output above. The two PWM channels for each PWM chip are not enabled. In Jessie, these are populated automatically at boot. How can I make that happen in stretch ? I could write a script, but I think that is done automatically through cape_manager in Jessie ?
I mean this hack fix is fairly trivial. Without the qep’s being enabled.
debian@wgd:~$ sudo su
root@wgd:/home/debian# cd ~
root@wgd:~# nano pwm-enable.sh
#!/bin/bash
echo ‘0’ > /sys/class/pwm/pwmchip0/export
echo ‘1’ > /sys/class/pwm/pwmchip0/export
echo ‘0’ > /sys/class/pwm/pwmchip2/export
echo ‘1’ > /sys/class/pwm/pwmchip2/export
echo ‘0’ > /sys/class/pwm/pwmchip4/export
echo ‘1’ > /sys/class/pwm/pwmchip4/export
exit 0
root@wgd:~# chmod +x pwm-enable.sh
root@wgd:~# ./pwm-enable.sh
root@wgd:~# ls /sys/class/pwm/pwmchip*/ |grep pwm
/sys/class/pwm/pwmchip0/:
npwm
pwm0
pwm1
/sys/class/pwm/pwmchip2/:
npwm
pwm0
pwm1
/sys/class/pwm/pwmchip4/:
npwm
pwm0
pwm1
What's happening in v4.4.x, the pwm's are now in the correct order, if
you look at v4.4.x: (pwm came before ecap)
#4.4.88-ti-r129
pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip0
pwmchip2 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip2
pwmchip4 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip4
pwmchip6 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip6
pwmchip7 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip7
In v4.9.x: (since ecap are considered pwm's) they are now in the order
of the register address:
pwmchip0 -> ../../devices/platform/ocp/48300000.epwmss/48300100.ecap/pwm/pwmchip0
pwmchip1 -> ../../devices/platform/ocp/48300000.epwmss/48300200.pwm/pwm/pwmchip1
pwmchip3 -> ../../devices/platform/ocp/48302000.epwmss/48302200.pwm/pwm/pwmchip3
pwmchip5 -> ../../devices/platform/ocp/48304000.epwmss/48304100.ecap/pwm/pwmchip5
pwmchip6 -> ../../devices/platform/ocp/48304000.epwmss/48304200.pwm/pwm/pwmchip6
In your case, you only want the dual mode "pwm", (48300200.pwm,
48302200.pwm, 48304200.pwm), you shouldn't blindly enable the
"pwmchip0,2,4" as they are dynamic. You should grep the symlink
first.
Ps, watch out for v4.11.x too:
#v4.4.x/v4.9.x
/sys/class/pwm/pwmchip1/:
drwxr-xr-x 3 root root 0 Sep 29 21:06 pwm0
drwxr-xr-x 3 root root 0 Sep 29 21:06 pwm1
#v4.11.x+
/sys/class/pwm/pwmchip1/:
drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:0
drwxrwxr-x 3 root pwm 0 Sep 29 21:10 pwm-1:1
(ps, this last change is good thing, notice that udev correctly added
the "root:pwm" rule.. 
)
Regards,
I think I have it figured out. If you disable the ecap devices, the dual channel populate normally. e.g. 0,2,4. But when you do have ecap enabled, that’s when things start to get squirrely. But at least it’s not completely random. There are or seem to be patterns when you have both ecap enabled. My file structure looked exactly the same as your above where you had ecap enabled.
I am trying to get p8_45 and p8_49 to run PWM2A and PWM2B signals. I am running 4.14.3-ti-r14 with
enable_uboot_overlays=1
enable_uboot_cape_universal=1
disable_uboot_overlay_video=1
According to the SRM that is possible, When I do an export to
echo 1 > /sys/class/pwm/pwmchip6/export
, I only get /sys/clas/pwm/pwm-6:1
With
echo 1 > /sys/class/pwm/pwmchip3/export
, I get /sys/clas/pwm/pwm-3:0 and /sys/clas/pwm/pwm-3:1.
Why is that? Should I do anything else?
OK, found out. Note to future self:
If you want /sys/clas/pwm/pwm-6:0, do an
echo 0 > /sys/class/pwm/pwmchip6/export
I misunderstood that echo 0> /sys/class/pwm/pwmchip3/export was an unexport to reset things.
To remove that channel, of course do a
echo 0> /sys/class/pwm/pwmchip6/unexport
and
echo 1> /sys/class/pwm/pwmchip6/unexport
After that, first do some pwm settings, eg:
echo 5000000 > /sys/class/pwm/pwmchip6/pwm-6:0/period
echo 5000000 > /sys/class/pwm/pwmchip6/pwm-6:0/duty_cycle
echo 5000000 > /sys/class/pwm/pwmchip6/pwm-6:1/period
echo 5000000 > /sys/class/pwm/pwmchip6/pwm-6:1/duty_cycle
and after that you can do
echo -n “1” > /sys/class/pwm/pwmchip6/pwm-6:0/enable
echo -n “1” > /sys/class/pwm/pwmchip6/pwm-6:1/enable
to have an effect.
If you first enable the stuff before doing any setttings on period or duty_cycle, the kernel will not allow it.