Stretch pwm difference

[William Hermans]

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.

[Robert Nelson]

On Wed, Sep 27, 2017 at 3:22 PM, William Hermans <yyr...@gmail.com> wrote:
> 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

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,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

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.

[William Hermans]

On Wed, Sep 27, 2017 at 1:31 PM, Robert Nelson <robert...@gmail.com> wrote:

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,

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 ?

[William Hermans]

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 ?

[William Hermans]

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

[Robert Nelson]

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.. ;) )

[William Hermans]

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.

[Johan Henselmans]

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?

[Johan Henselmans]

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.