How to set PWM tunable name to ehrpwm.1 ?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

How to set PWM tunable name to ehrpwm.1 ?

Nicola Mingotti
Hi,

In my BeagleBone Black, FreeBSD-12 RELEASE, i created two overlays,
pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22 and
respectively p9.14, p9.16. DTSO files are below.

If I load both the DTBO at boot I see correctly|ehrpwm.0|and|ehrpwm.1|,
associated to the correct pins. But, if i remove the
overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which is not
what i want, i would like to see the name|ehrpwm.1|.

This is important because i must be 100% sure a certain pin corresponds
the a certain tunable.This must be true even if i remove non relevant
overlays in the future. I guess there must be some parameter in the DTSO
which i don't know, i hope you can give me some directions about that.

bye
Nicola

-------- pwm.dtso -----------------

|/dts-v1/; /plugin/; / { compatible = "ti,am335x-bone-black",
"ti,am335x-bone", "ti,am33xx"; exclusive-use =
"P9.21","P9.22","ehrpwm0_AB"; }; &am33xx_pinmux { ehrpwm0_AB_pins:
pinmux_ehrpwm0_AB_pins { pinctrl-single,pins = < 0x154 0x03 /* P9.21 */
0x150 0x03 /* P9.22 */ >; }; }; &ehrpwm0 { status = "okay";
pinctrl-names = "default"; pinctrl-0 = <&ehrpwm0_AB_pins>; }; &epwmss0 {
status = "okay"; }; &ecap0 { status = "okay"; };
-----------------------------------------------------------
--------------------- pwm1.dtso -------------------------- |
||/dts-v1/; /plugin/; / { compatible = "ti,am335x-bone-black",
"ti,am335x-bone", "ti,am33xx"; exclusive-use =
"P9.14","P9.16","ehrpwm1_AB"; }; &am33xx_pinmux { ehrpwm1_AB_pins:
pinmux_ehrpwm1_AB_pins { pinctrl-single,pins = < 0x048 0x06 /* P9.14 */
0x04C 0x06 /* P9.16 */ >; }; }; &ehrpwm1 { status = "okay";
pinctrl-names = "default"; pinctrl-0 = <&ehrpwm1_AB_pins>; }; &epwmss1 {
status = "okay"; }; &ecap1 { status = "okay"; };
|----------------------------------------------------------- |

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Sergey Manucharian
Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:

>
> In my BeagleBone Black, FreeBSD-12 RELEASE, i created two overlays,
> pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22 and
> respectively p9.14, p9.16. DTSO files are below.
>
> If I load both the DTBO at boot I see correctly|ehrpwm.0|and|ehrpwm.1|,
> associated to the correct pins. But, if i remove the
> overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which is not
> what i want, i would like to see the name|ehrpwm.1|.
>
> This is important because i must be 100% sure a certain pin corresponds
> the a certain tunable.This must be true even if i remove non relevant
> overlays in the future. I guess there must be some parameter in the DTSO
> which i don't know, i hope you can give me some directions about that.

It is not related to your DTBO's. That's how everything works (at least
by default). You will see the same naming issue with serial ports, for
example. And not just in BBB.

E.g. when I have enabled uart0 and uart2 they are named ttyu0 and ttyu1,
if I have only uart2, it becomes ttyu0.

It's easier if there is a device node in /dev, so you can create a symlink
with a fixed name (I have a script called by devd for my multiple serial
ports). However, that's not the case with PWM...

Maybe there is an option to use persistent names for devices that somebody
can point to.

S.

> /dts-v1/;
> /plugin/;
>
> / {
>     compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
>     exclusive-use =
>     "P9.21","P9.22","ehrpwm0_AB";
> };
>
> &am33xx_pinmux {
> ehrpwm0_AB_pins: pinmux_ehrpwm0_AB_pins {
>     pinctrl-single,pins = <
>         0x154 0x03 /* P9.21 */
>         0x150 0x03 /* P9.22 */
>         >;
>     };
> };
>
> &ehrpwm0 {
>     status = "okay";
>     pinctrl-names = "default";
>     pinctrl-0 = <&ehrpwm0_AB_pins>; };
> &epwmss0 {
>     status = "okay";
> };
> &ecap0 {
>     status = "okay";
> };
>
> /dts-v1/;
> /plugin/;
> / {
>     compatible = "ti,am335x-bone-black","ti,am335x-bone", "ti,am33xx";
>     exclusive-use =
>     "P9.14","P9.16","ehrpwm1_AB";
> };
>
> &am33xx_pinmux {
> ehrpwm1_AB_pins: pinmux_ehrpwm1_AB_pins {
>     pinctrl-single,pins = <
>         0x048 0x06 /* P9.14 */
>         0x04C 0x06 /* P9.16 */
>         >;
>     };
> };
>
> &ehrpwm1 {
>     status = "okay";
>     pinctrl-names = "default";
>     pinctrl-0 = <&ehrpwm1_AB_pins>;
> };
>
> &epwmss1 {
>     status = "okay";
> };
>
> &ecap1 {
>     status = "okay";
> };
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Ian Lepore-3
On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:

> Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
> >
> > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > overlays,
> > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22 and
> > respectively p9.14, p9.16. DTSO files are below.
> >
> > If I load both the DTBO at boot I see
> > correctly|ehrpwm.0|and|ehrpwm.1|,
> > associated to the correct pins. But, if i remove the
> > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which is
> > not
> > what i want, i would like to see the name|ehrpwm.1|.
> >
> > This is important because i must be 100% sure a certain pin
> > corresponds
> > the a certain tunable.This must be true even if i remove non
> > relevant
> > overlays in the future. I guess there must be some parameter in the
> > DTSO
> > which i don't know, i hope you can give me some directions about
> > that.
>
> It is not related to your DTBO's. That's how everything works (at
> least
> by default). You will see the same naming issue with serial ports,
> for
> example. And not just in BBB.
>
> E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
> ttyu1,
> if I have only uart2, it becomes ttyu0.
>
> It's easier if there is a device node in /dev, so you can create a
> symlink
> with a fixed name (I have a script called by devd for my multiple
> serial
> ports). However, that's not the case with PWM...
>
> Maybe there is an option to use persistent names for devices that
> somebody
> can point to.
>

Nope, there's no magic thing you're missing that fixes this.  Devices
get named-and-numbered based on the order of instantiation.

Since what really matters here is the sysctl names, we could change the
driver to install the sysctl nodes using the fdt device node names
instead of the freebsd newbus device names.  Hmm, actually, since
people may be relying on the current names, I guess what we'd have to
do is install another set of sysctl names based on fdt name (basically
a set of alias names).

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Nicola Mingotti


On 6/6/19 3:40 PM, Ian Lepore wrote:

> On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
>> Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
>>> In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
>>> overlays,
>>> pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22 and
>>> respectively p9.14, p9.16. DTSO files are below.
>>>
>>> If I load both the DTBO at boot I see
>>> correctly|ehrpwm.0|and|ehrpwm.1|,
>>> associated to the correct pins. But, if i remove the
>>> overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which is
>>> not
>>> what i want, i would like to see the name|ehrpwm.1|.
>>>
>>> This is important because i must be 100% sure a certain pin
>>> corresponds
>>> the a certain tunable.This must be true even if i remove non
>>> relevant
>>> overlays in the future. I guess there must be some parameter in the
>>> DTSO
>>> which i don't know, i hope you can give me some directions about
>>> that.
>> It is not related to your DTBO's. That's how everything works (at
>> least
>> by default). You will see the same naming issue with serial ports,
>> for
>> example. And not just in BBB.
>>
>> E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
>> ttyu1,
>> if I have only uart2, it becomes ttyu0.
>>
>> It's easier if there is a device node in /dev, so you can create a
>> symlink
>> with a fixed name (I have a script called by devd for my multiple
>> serial
>> ports). However, that's not the case with PWM...
>>
>> Maybe there is an option to use persistent names for devices that
>> somebody
>> can point to.
>>
> Nope, there's no magic thing you're missing that fixes this.  Devices
> get named-and-numbered based on the order of instantiation.
>
> Since what really matters here is the sysctl names, we could change the
> driver to install the sysctl nodes using the fdt device node names
> instead of the freebsd newbus device names.  Hmm, actually, since
> people may be relying on the current names, I guess what we'd have to
> do is install another set of sysctl names based on fdt name (basically
> a set of alias names).
>
> -- Ian
>

I see, I agree changing the default naming scheme may damage who is
relaying on it. It is not a good idea. Maybe it could be implemented in
release 13.

To Sergey. I used devd in the past, it works well. But i would prefer
not to use it in this case, even if I had a /dev/xyz file available. The
reason is that the /dev/xyz file would appear before the the devd daemon
starts up (i guess), so the case would not stricly be covered by what
the devd man page says devd should do.
$> man devd
=> " ... Whenever a device is added to or removed from the device tree ... "

To Ian. The idea of the alias seems good. I don't know at all what you
can manage to do at the kernel level with the tunables. I imagine
something like |dev.alias.am335x_ehrpwm.1| which actually refers to
|EHRPWM1| not the second |ehrpwm| that got plugged into the system via
overlay.

Thank you for your answers

goodbye
Nicola










_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Bernd Walter-4
On Fri, Jun 07, 2019 at 02:08:32AM -0700, Nicola Mingotti wrote:

>
>
> On 6/6/19 3:40 PM, Ian Lepore wrote:
> >On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> >>Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
> >>>In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> >>>overlays,
> >>>pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22 and
> >>>respectively p9.14, p9.16. DTSO files are below.
> >>>
> >>>If I load both the DTBO at boot I see
> >>>correctly|ehrpwm.0|and|ehrpwm.1|,
> >>>associated to the correct pins. But, if i remove the
> >>>overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which is
> >>>not
> >>>what i want, i would like to see the name|ehrpwm.1|.
> >>>
> >>>This is important because i must be 100% sure a certain pin
> >>>corresponds
> >>>the a certain tunable.This must be true even if i remove non
> >>>relevant
> >>>overlays in the future. I guess there must be some parameter in the
> >>>DTSO
> >>>which i don't know, i hope you can give me some directions about
> >>>that.
> >>It is not related to your DTBO's. That's how everything works (at
> >>least
> >>by default). You will see the same naming issue with serial ports,
> >>for
> >>example. And not just in BBB.
> >>
> >>E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
> >>ttyu1,
> >>if I have only uart2, it becomes ttyu0.
> >>
> >>It's easier if there is a device node in /dev, so you can create a
> >>symlink
> >>with a fixed name (I have a script called by devd for my multiple
> >>serial
> >>ports). However, that's not the case with PWM...
> >>
> >>Maybe there is an option to use persistent names for devices that
> >>somebody
> >>can point to.
> >>
> >Nope, there's no magic thing you're missing that fixes this.  Devices
> >get named-and-numbered based on the order of instantiation.
> >
> >Since what really matters here is the sysctl names, we could change the
> >driver to install the sysctl nodes using the fdt device node names
> >instead of the freebsd newbus device names.  Hmm, actually, since
> >people may be relying on the current names, I guess what we'd have to
> >do is install another set of sysctl names based on fdt name (basically
> >a set of alias names).
> >
> >-- Ian
> >
>
> I see, I agree changing the default naming scheme may damage who is
> relaying on it. It is not a good idea. Maybe it could be implemented in
> release 13.
>
> To Sergey. I used devd in the past, it works well. But i would prefer
> not to use it in this case, even if I had a /dev/xyz file available. The
> reason is that the /dev/xyz file would appear before the the devd daemon
> starts up (i guess), so the case would not stricly be covered by what
> the devd man page says devd should do.
> $> man devd
> => " ... Whenever a device is added to or removed from the device tree ... "
>
> To Ian. The idea of the alias seems good. I don't know at all what you
> can manage to do at the kernel level with the tunables. I imagine
> something like |dev.alias.am335x_ehrpwm.1| which actually refers to
> |EHRPWM1| not the second |ehrpwm| that got plugged into the system via
> overlay.
>
> Thank you for your answers

I don't know if it would work for you, but I'm a happy user of devd for
such things.
This is devinfo -rv on a Pine64:
...
      uart0 pnpinfo name=serial@1c28000 compat=snps,dw-apb-uart
...
I assume it is similar to what you should see on the beaglebone.
It should be easy to identify a specific device via the name= entry.
Messages to devd gets queued up and it shouldn't matter if the device is
already attached when devd starts.

This is what I use for USB uarts:
attach 0 {
        device-name             "uftdi[0-9]+";
        match "sernum"          "FTYY82HD";
        match "interface"       "0";
        action                  "rm /dev/manson_psu5; ln -s /dev/cua$ttyname /dev/manson_psu5";
};

Since uart(4) doen't offer a nice $ttyname, you have to convert the
device-name into the matching cuau* entry.

--
B.Walter <[hidden email]> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Ian Lepore-3
In reply to this post by Nicola Mingotti
On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote:

>
> On 6/6/19 3:40 PM, Ian Lepore wrote:
> > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
> > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > > > overlays,
> > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22
> > > > and
> > > > respectively p9.14, p9.16. DTSO files are below.
> > > >
> > > > If I load both the DTBO at boot I see
> > > > correctly|ehrpwm.0|and|ehrpwm.1|,
> > > > associated to the correct pins. But, if i remove the
> > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which
> > > > is
> > > > not
> > > > what i want, i would like to see the name|ehrpwm.1|.
> > > >
> > > > This is important because i must be 100% sure a certain pin
> > > > corresponds
> > > > the a certain tunable.This must be true even if i remove non
> > > > relevant
> > > > overlays in the future. I guess there must be some parameter in
> > > > the
> > > > DTSO
> > > > which i don't know, i hope you can give me some directions
> > > > about
> > > > that.
> > >
> > > It is not related to your DTBO's. That's how everything works (at
> > > least
> > > by default). You will see the same naming issue with serial
> > > ports,
> > > for
> > > example. And not just in BBB.
> > >
> > > E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
> > > ttyu1,
> > > if I have only uart2, it becomes ttyu0.
> > >
> > > It's easier if there is a device node in /dev, so you can create
> > > a
> > > symlink
> > > with a fixed name (I have a script called by devd for my multiple
> > > serial
> > > ports). However, that's not the case with PWM...
> > >
> > > Maybe there is an option to use persistent names for devices that
> > > somebody
> > > can point to.
> > >
> >
> > Nope, there's no magic thing you're missing that fixes
> > this.  Devices
> > get named-and-numbered based on the order of instantiation.
> >
> > Since what really matters here is the sysctl names, we could change
> > the
> > driver to install the sysctl nodes using the fdt device node names
> > instead of the freebsd newbus device names.  Hmm, actually, since
> > people may be relying on the current names, I guess what we'd have
> > to
> > do is install another set of sysctl names based on fdt name
> > (basically
> > a set of alias names).
> >
> > -- Ian
> >
>
> I see, I agree changing the default naming scheme may damage who is
> relaying on it. It is not a good idea. Maybe it could be implemented
> in
> release 13.
>
> To Sergey. I used devd in the past, it works well. But i would
> prefer
> not to use it in this case, even if I had a /dev/xyz file available.
> The
> reason is that the /dev/xyz file would appear before the the devd
> daemon
> starts up (i guess), so the case would not stricly be covered by
> what
> the devd man page says devd should do.
> $> man devd
> => " ... Whenever a device is added to or removed from the device
> tree ... "
>
> To Ian. The idea of the alias seems good. I don't know at all what
> you
> can manage to do at the kernel level with the tunables. I imagine
> something like |dev.alias.am335x_ehrpwm.1| which actually refers to
> > EHRPWM1| not the second |ehrpwm| that got plugged into the system
> > via
>
> overlay.
>
> Thank you for your answers
>
>

The dev.* hierarchy is managed by newbus; what I was picturing was
something like hw.ehrpwm1.freq and so on, settable as either tunable or
sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
accessible at runtime.  The actual node name is just 'pwm' and really,
nothing prevents upstream from changing that name on a whim next time
we import new dts files.  (And linux sure seems to have a lot of
arbitrary whims when it comes to changing dts.)

Since an overlay is required to use this stuff anyway, I'm now thinking
a custom property in the overlay that names the sysctl nodes might be a
good option.  So you'd add a property like:

   &ehrpwm0 {
       status = "okay";
       pinctrl-names = "default";
       pinctrl-0 = <&ehrpwm0_AB_pins>;
       freebsd,sysctl = "backlight";
   };

And that would make it install names like hw.backlight.freq and
hw.backlight.period and so on.  If you don't add that property, it just
installs the names it uses now (dev.ehrpwm.*) for compatibility.

-- Ian


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Ian Lepore-3
In reply to this post by Bernd Walter-4
On Fri, 2019-06-07 at 13:24 +0200, Bernd Walter wrote:

> On Fri, Jun 07, 2019 at 02:08:32AM -0700, Nicola Mingotti wrote:
> >
> >
> > On 6/6/19 3:40 PM, Ian Lepore wrote:
> > > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> > > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19
> > > > 12:33:
> > > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > > > > overlays,
> > > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22
> > > > > and
> > > > > respectively p9.14, p9.16. DTSO files are below.
> > > > >
> > > > > If I load both the DTBO at boot I see
> > > > > correctly|ehrpwm.0|and|ehrpwm.1|,
> > > > > associated to the correct pins. But, if i remove the
> > > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|,
> > > > > which is
> > > > > not
> > > > > what i want, i would like to see the name|ehrpwm.1|.
> > > > >
> > > > > This is important because i must be 100% sure a certain pin
> > > > > corresponds
> > > > > the a certain tunable.This must be true even if i remove non
> > > > > relevant
> > > > > overlays in the future. I guess there must be some parameter
> > > > > in the
> > > > > DTSO
> > > > > which i don't know, i hope you can give me some directions
> > > > > about
> > > > > that.
> > > >
> > > > It is not related to your DTBO's. That's how everything works
> > > > (at
> > > > least
> > > > by default). You will see the same naming issue with serial
> > > > ports,
> > > > for
> > > > example. And not just in BBB.
> > > >
> > > > E.g. when I have enabled uart0 and uart2 they are named ttyu0
> > > > and
> > > > ttyu1,
> > > > if I have only uart2, it becomes ttyu0.
> > > >
> > > > It's easier if there is a device node in /dev, so you can
> > > > create a
> > > > symlink
> > > > with a fixed name (I have a script called by devd for my
> > > > multiple
> > > > serial
> > > > ports). However, that's not the case with PWM...
> > > >
> > > > Maybe there is an option to use persistent names for devices
> > > > that
> > > > somebody
> > > > can point to.
> > > >
> > >
> > > Nope, there's no magic thing you're missing that fixes
> > > this.  Devices
> > > get named-and-numbered based on the order of instantiation.
> > >
> > > Since what really matters here is the sysctl names, we could
> > > change the
> > > driver to install the sysctl nodes using the fdt device node
> > > names
> > > instead of the freebsd newbus device names.  Hmm, actually, since
> > > people may be relying on the current names, I guess what we'd
> > > have to
> > > do is install another set of sysctl names based on fdt name
> > > (basically
> > > a set of alias names).
> > >
> > > -- Ian
> > >
> >
> > I see, I agree changing the default naming scheme may damage who
> > is
> > relaying on it. It is not a good idea. Maybe it could be
> > implemented in
> > release 13.
> >
> > To Sergey. I used devd in the past, it works well. But i would
> > prefer
> > not to use it in this case, even if I had a /dev/xyz file
> > available. The
> > reason is that the /dev/xyz file would appear before the the devd
> > daemon
> > starts up (i guess), so the case would not stricly be covered by
> > what
> > the devd man page says devd should do.
> > $> man devd
> > => " ... Whenever a device is added to or removed from the device
> > tree ... "
> >
> > To Ian. The idea of the alias seems good. I don't know at all what
> > you
> > can manage to do at the kernel level with the tunables. I imagine
> > something like |dev.alias.am335x_ehrpwm.1| which actually refers
> > to
> > > EHRPWM1| not the second |ehrpwm| that got plugged into the system
> > > via
> >
> > overlay.
> >
> > Thank you for your answers
>
> I don't know if it would work for you, but I'm a happy user of devd
> for
> such things.
> This is devinfo -rv on a Pine64:
> ...
>       uart0 pnpinfo name=serial@1c28000 compat=snps,dw-apb-uart
> ...
> I assume it is similar to what you should see on the beaglebone.
> It should be easy to identify a specific device via the name= entry.
> Messages to devd gets queued up and it shouldn't matter if the device
> is
> already attached when devd starts.
>
> This is what I use for USB uarts:
> attach 0 {
>         device-name             "uftdi[0-9]+";
>         match "sernum"          "FTYY82HD";
>         match "interface"       "0";
>         action                  "rm /dev/manson_psu5; ln -s
> /dev/cua$ttyname /dev/manson_psu5";
> };
>
> Since uart(4) doen't offer a nice $ttyname, you have to convert the
> device-name into the matching cuau* entry.
>

Not quite the same thing.  You're using a devd rule to manipulate
things in devfs.  We're talking about sysctl nodes which are named
after the newbus device.  It would be the equivelent of making the ftdi
driver install sysctl nodes that were named something other than
dev.uftdi.*.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Emmanuel Vadot-7
In reply to this post by Ian Lepore-3
On Fri, 07 Jun 2019 08:58:49 -0600
Ian Lepore <[hidden email]> wrote:

> On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote:
> >
> > On 6/6/19 3:40 PM, Ian Lepore wrote:
> > > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> > > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
> > > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > > > > overlays,
> > > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22
> > > > > and
> > > > > respectively p9.14, p9.16. DTSO files are below.
> > > > >
> > > > > If I load both the DTBO at boot I see
> > > > > correctly|ehrpwm.0|and|ehrpwm.1|,
> > > > > associated to the correct pins. But, if i remove the
> > > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which
> > > > > is
> > > > > not
> > > > > what i want, i would like to see the name|ehrpwm.1|.
> > > > >
> > > > > This is important because i must be 100% sure a certain pin
> > > > > corresponds
> > > > > the a certain tunable.This must be true even if i remove non
> > > > > relevant
> > > > > overlays in the future. I guess there must be some parameter in
> > > > > the
> > > > > DTSO
> > > > > which i don't know, i hope you can give me some directions
> > > > > about
> > > > > that.
> > > >
> > > > It is not related to your DTBO's. That's how everything works (at
> > > > least
> > > > by default). You will see the same naming issue with serial
> > > > ports,
> > > > for
> > > > example. And not just in BBB.
> > > >
> > > > E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
> > > > ttyu1,
> > > > if I have only uart2, it becomes ttyu0.
> > > >
> > > > It's easier if there is a device node in /dev, so you can create
> > > > a
> > > > symlink
> > > > with a fixed name (I have a script called by devd for my multiple
> > > > serial
> > > > ports). However, that's not the case with PWM...
> > > >
> > > > Maybe there is an option to use persistent names for devices that
> > > > somebody
> > > > can point to.
> > > >
> > >
> > > Nope, there's no magic thing you're missing that fixes
> > > this.  Devices
> > > get named-and-numbered based on the order of instantiation.
> > >
> > > Since what really matters here is the sysctl names, we could change
> > > the
> > > driver to install the sysctl nodes using the fdt device node names
> > > instead of the freebsd newbus device names.  Hmm, actually, since
> > > people may be relying on the current names, I guess what we'd have
> > > to
> > > do is install another set of sysctl names based on fdt name
> > > (basically
> > > a set of alias names).
> > >
> > > -- Ian
> > >
> >
> > I see, I agree changing the default naming scheme may damage who is
> > relaying on it. It is not a good idea. Maybe it could be implemented
> > in
> > release 13.
> >
> > To Sergey. I used devd in the past, it works well. But i would
> > prefer
> > not to use it in this case, even if I had a /dev/xyz file available.
> > The
> > reason is that the /dev/xyz file would appear before the the devd
> > daemon
> > starts up (i guess), so the case would not stricly be covered by
> > what
> > the devd man page says devd should do.
> > $> man devd
> > => " ... Whenever a device is added to or removed from the device
> > tree ... "
> >
> > To Ian. The idea of the alias seems good. I don't know at all what
> > you
> > can manage to do at the kernel level with the tunables. I imagine
> > something like |dev.alias.am335x_ehrpwm.1| which actually refers to
> > > EHRPWM1| not the second |ehrpwm| that got plugged into the system
> > > via
> >
> > overlay.
> >
> > Thank you for your answers
> >
> >
>
> The dev.* hierarchy is managed by newbus; what I was picturing was
> something like hw.ehrpwm1.freq and so on, settable as either tunable or
> sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
> accessible at runtime.  The actual node name is just 'pwm' and really,
> nothing prevents upstream from changing that name on a whim next time
> we import new dts files.  (And linux sure seems to have a lot of
> arbitrary whims when it comes to changing dts.)

 Relying on the name is clearly not a good idea, especially for TI
since they change stuff A LOT.

> Since an overlay is required to use this stuff anyway, I'm now thinking
> a custom property in the overlay that names the sysctl nodes might be a
> good option.  So you'd add a property like:
>
>    &ehrpwm0 {
>        status = "okay";
>        pinctrl-names = "default";
>        pinctrl-0 = <&ehrpwm0_AB_pins>;
>        freebsd,sysctl = "backlight";
>    };
>
> And that would make it install names like hw.backlight.freq and
> hw.backlight.period and so on.  If you don't add that property, it just
> installs the names it uses now (dev.ehrpwm.*) for compatibility.
>
> -- Ian

 What would be better is to add support to the pwm(9) api for this
driver and make the api and pwm(8) using the "pwm-names" property which
is a standard one from the bindings.

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Warner Losh
On Fri, Jun 7, 2019 at 9:11 AM Emmanuel Vadot <[hidden email]> wrote:

> On Fri, 07 Jun 2019 08:58:49 -0600
> Ian Lepore <[hidden email]> wrote:
>
> > On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote:
> > >
> > > On 6/6/19 3:40 PM, Ian Lepore wrote:
> > > > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> > > > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
> > > > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > > > > > overlays,
> > > > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22
> > > > > > and
> > > > > > respectively p9.14, p9.16. DTSO files are below.
> > > > > >
> > > > > > If I load both the DTBO at boot I see
> > > > > > correctly|ehrpwm.0|and|ehrpwm.1|,
> > > > > > associated to the correct pins. But, if i remove the
> > > > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which
> > > > > > is
> > > > > > not
> > > > > > what i want, i would like to see the name|ehrpwm.1|.
> > > > > >
> > > > > > This is important because i must be 100% sure a certain pin
> > > > > > corresponds
> > > > > > the a certain tunable.This must be true even if i remove non
> > > > > > relevant
> > > > > > overlays in the future. I guess there must be some parameter in
> > > > > > the
> > > > > > DTSO
> > > > > > which i don't know, i hope you can give me some directions
> > > > > > about
> > > > > > that.
> > > > >
> > > > > It is not related to your DTBO's. That's how everything works (at
> > > > > least
> > > > > by default). You will see the same naming issue with serial
> > > > > ports,
> > > > > for
> > > > > example. And not just in BBB.
> > > > >
> > > > > E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
> > > > > ttyu1,
> > > > > if I have only uart2, it becomes ttyu0.
> > > > >
> > > > > It's easier if there is a device node in /dev, so you can create
> > > > > a
> > > > > symlink
> > > > > with a fixed name (I have a script called by devd for my multiple
> > > > > serial
> > > > > ports). However, that's not the case with PWM...
> > > > >
> > > > > Maybe there is an option to use persistent names for devices that
> > > > > somebody
> > > > > can point to.
> > > > >
> > > >
> > > > Nope, there's no magic thing you're missing that fixes
> > > > this.  Devices
> > > > get named-and-numbered based on the order of instantiation.
> > > >
> > > > Since what really matters here is the sysctl names, we could change
> > > > the
> > > > driver to install the sysctl nodes using the fdt device node names
> > > > instead of the freebsd newbus device names.  Hmm, actually, since
> > > > people may be relying on the current names, I guess what we'd have
> > > > to
> > > > do is install another set of sysctl names based on fdt name
> > > > (basically
> > > > a set of alias names).
> > > >
> > > > -- Ian
> > > >
> > >
> > > I see, I agree changing the default naming scheme may damage who is
> > > relaying on it. It is not a good idea. Maybe it could be implemented
> > > in
> > > release 13.
> > >
> > > To Sergey. I used devd in the past, it works well. But i would
> > > prefer
> > > not to use it in this case, even if I had a /dev/xyz file available.
> > > The
> > > reason is that the /dev/xyz file would appear before the the devd
> > > daemon
> > > starts up (i guess), so the case would not stricly be covered by
> > > what
> > > the devd man page says devd should do.
> > > $> man devd
> > > => " ... Whenever a device is added to or removed from the device
> > > tree ... "
> > >
> > > To Ian. The idea of the alias seems good. I don't know at all what
> > > you
> > > can manage to do at the kernel level with the tunables. I imagine
> > > something like |dev.alias.am335x_ehrpwm.1| which actually refers to
> > > > EHRPWM1| not the second |ehrpwm| that got plugged into the system
> > > > via
> > >
> > > overlay.
> > >
> > > Thank you for your answers
> > >
> > >
> >
> > The dev.* hierarchy is managed by newbus; what I was picturing was
> > something like hw.ehrpwm1.freq and so on, settable as either tunable or
> > sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
> > accessible at runtime.  The actual node name is just 'pwm' and really,
> > nothing prevents upstream from changing that name on a whim next time
> > we import new dts files.  (And linux sure seems to have a lot of
> > arbitrary whims when it comes to changing dts.)
>
>  Relying on the name is clearly not a good idea, especially for TI
> since they change stuff A LOT.
>
> > Since an overlay is required to use this stuff anyway, I'm now thinking
> > a custom property in the overlay that names the sysctl nodes might be a
> > good option.  So you'd add a property like:
> >
> >    &ehrpwm0 {
> >        status = "okay";
> >        pinctrl-names = "default";
> >        pinctrl-0 = <&ehrpwm0_AB_pins>;
> >        freebsd,sysctl = "backlight";
> >    };
> >
> > And that would make it install names like hw.backlight.freq and
> > hw.backlight.period and so on.  If you don't add that property, it just
> > installs the names it uses now (dev.ehrpwm.*) for compatibility.
> >
> > -- Ian
>
>  What would be better is to add support to the pwm(9) api for this
> driver and make the api and pwm(8) using the "pwm-names" property which
> is a standard one from the bindings.
>

For this specific case, I think that's great. I'd go farther than say we
should have the FDT/OFW node name, if any, associated with something like
dev.<dev>.<unit>.node_name.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Emmanuel Vadot-7
On Fri, 7 Jun 2019 09:17:01 -0600
Warner Losh <[hidden email]> wrote:

> On Fri, Jun 7, 2019 at 9:11 AM Emmanuel Vadot <[hidden email]> wrote:
>
> > On Fri, 07 Jun 2019 08:58:49 -0600
> > Ian Lepore <[hidden email]> wrote:
> >
> > > On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote:
> > > >
> > > > On 6/6/19 3:40 PM, Ian Lepore wrote:
> > > > > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> > > > > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
> > > > > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > > > > > > overlays,
> > > > > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22
> > > > > > > and
> > > > > > > respectively p9.14, p9.16. DTSO files are below.
> > > > > > >
> > > > > > > If I load both the DTBO at boot I see
> > > > > > > correctly|ehrpwm.0|and|ehrpwm.1|,
> > > > > > > associated to the correct pins. But, if i remove the
> > > > > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which
> > > > > > > is
> > > > > > > not
> > > > > > > what i want, i would like to see the name|ehrpwm.1|.
> > > > > > >
> > > > > > > This is important because i must be 100% sure a certain pin
> > > > > > > corresponds
> > > > > > > the a certain tunable.This must be true even if i remove non
> > > > > > > relevant
> > > > > > > overlays in the future. I guess there must be some parameter in
> > > > > > > the
> > > > > > > DTSO
> > > > > > > which i don't know, i hope you can give me some directions
> > > > > > > about
> > > > > > > that.
> > > > > >
> > > > > > It is not related to your DTBO's. That's how everything works (at
> > > > > > least
> > > > > > by default). You will see the same naming issue with serial
> > > > > > ports,
> > > > > > for
> > > > > > example. And not just in BBB.
> > > > > >
> > > > > > E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
> > > > > > ttyu1,
> > > > > > if I have only uart2, it becomes ttyu0.
> > > > > >
> > > > > > It's easier if there is a device node in /dev, so you can create
> > > > > > a
> > > > > > symlink
> > > > > > with a fixed name (I have a script called by devd for my multiple
> > > > > > serial
> > > > > > ports). However, that's not the case with PWM...
> > > > > >
> > > > > > Maybe there is an option to use persistent names for devices that
> > > > > > somebody
> > > > > > can point to.
> > > > > >
> > > > >
> > > > > Nope, there's no magic thing you're missing that fixes
> > > > > this.  Devices
> > > > > get named-and-numbered based on the order of instantiation.
> > > > >
> > > > > Since what really matters here is the sysctl names, we could change
> > > > > the
> > > > > driver to install the sysctl nodes using the fdt device node names
> > > > > instead of the freebsd newbus device names.  Hmm, actually, since
> > > > > people may be relying on the current names, I guess what we'd have
> > > > > to
> > > > > do is install another set of sysctl names based on fdt name
> > > > > (basically
> > > > > a set of alias names).
> > > > >
> > > > > -- Ian
> > > > >
> > > >
> > > > I see, I agree changing the default naming scheme may damage who is
> > > > relaying on it. It is not a good idea. Maybe it could be implemented
> > > > in
> > > > release 13.
> > > >
> > > > To Sergey. I used devd in the past, it works well. But i would
> > > > prefer
> > > > not to use it in this case, even if I had a /dev/xyz file available.
> > > > The
> > > > reason is that the /dev/xyz file would appear before the the devd
> > > > daemon
> > > > starts up (i guess), so the case would not stricly be covered by
> > > > what
> > > > the devd man page says devd should do.
> > > > $> man devd
> > > > => " ... Whenever a device is added to or removed from the device
> > > > tree ... "
> > > >
> > > > To Ian. The idea of the alias seems good. I don't know at all what
> > > > you
> > > > can manage to do at the kernel level with the tunables. I imagine
> > > > something like |dev.alias.am335x_ehrpwm.1| which actually refers to
> > > > > EHRPWM1| not the second |ehrpwm| that got plugged into the system
> > > > > via
> > > >
> > > > overlay.
> > > >
> > > > Thank you for your answers
> > > >
> > > >
> > >
> > > The dev.* hierarchy is managed by newbus; what I was picturing was
> > > something like hw.ehrpwm1.freq and so on, settable as either tunable or
> > > sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
> > > accessible at runtime.  The actual node name is just 'pwm' and really,
> > > nothing prevents upstream from changing that name on a whim next time
> > > we import new dts files.  (And linux sure seems to have a lot of
> > > arbitrary whims when it comes to changing dts.)
> >
> >  Relying on the name is clearly not a good idea, especially for TI
> > since they change stuff A LOT.
> >
> > > Since an overlay is required to use this stuff anyway, I'm now thinking
> > > a custom property in the overlay that names the sysctl nodes might be a
> > > good option.  So you'd add a property like:
> > >
> > >    &ehrpwm0 {
> > >        status = "okay";
> > >        pinctrl-names = "default";
> > >        pinctrl-0 = <&ehrpwm0_AB_pins>;
> > >        freebsd,sysctl = "backlight";
> > >    };
> > >
> > > And that would make it install names like hw.backlight.freq and
> > > hw.backlight.period and so on.  If you don't add that property, it just
> > > installs the names it uses now (dev.ehrpwm.*) for compatibility.
> > >
> > > -- Ian
> >
> >  What would be better is to add support to the pwm(9) api for this
> > driver and make the api and pwm(8) using the "pwm-names" property which
> > is a standard one from the bindings.
> >
>
> For this specific case, I think that's great. I'd go farther than say we
> should have the FDT/OFW node name, if any, associated with something like
> dev.<dev>.<unit>.node_name.
>
> Warner

 I like that idea too, I'll look at it this weekend, that should not be
hard to do.

--
Emmanuel Vadot <[hidden email]> <[hidden email]>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Ian Lepore-3
In reply to this post by Warner Losh
On Fri, 2019-06-07 at 09:17 -0600, Warner Losh wrote:

> On Fri, Jun 7, 2019 at 9:11 AM Emmanuel Vadot <[hidden email]>
> wrote:
>
> > On Fri, 07 Jun 2019 08:58:49 -0600
> > Ian Lepore <[hidden email]> wrote:
> >
> > > On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote:
> > > >
> > > > On 6/6/19 3:40 PM, Ian Lepore wrote:
> > > > > On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
> > > > > > Excerpts from Nicola Mingotti's message from Thu 06-Jun-19
> > > > > > 12:33:
> > > > > > > In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
> > > > > > > overlays,
> > > > > > > pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21,
> > > > > > > p9.22
> > > > > > > and
> > > > > > > respectively p9.14, p9.16. DTSO files are below.
> > > > > > >
> > > > > > > If I load both the DTBO at boot I see
> > > > > > > correctly|ehrpwm.0|and|ehrpwm.1|,
> > > > > > > associated to the correct pins. But, if i remove the
> > > > > > > overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|,
> > > > > > > which
> > > > > > > is
> > > > > > > not
> > > > > > > what i want, i would like to see the name|ehrpwm.1|.
> > > > > > >
> > > > > > > This is important because i must be 100% sure a certain
> > > > > > > pin
> > > > > > > corresponds
> > > > > > > the a certain tunable.This must be true even if i remove
> > > > > > > non
> > > > > > > relevant
> > > > > > > overlays in the future. I guess there must be some
> > > > > > > parameter in
> > > > > > > the
> > > > > > > DTSO
> > > > > > > which i don't know, i hope you can give me some
> > > > > > > directions
> > > > > > > about
> > > > > > > that.
> > > > > >
> > > > > > It is not related to your DTBO's. That's how everything
> > > > > > works (at
> > > > > > least
> > > > > > by default). You will see the same naming issue with serial
> > > > > > ports,
> > > > > > for
> > > > > > example. And not just in BBB.
> > > > > >
> > > > > > E.g. when I have enabled uart0 and uart2 they are named
> > > > > > ttyu0 and
> > > > > > ttyu1,
> > > > > > if I have only uart2, it becomes ttyu0.
> > > > > >
> > > > > > It's easier if there is a device node in /dev, so you can
> > > > > > create
> > > > > > a
> > > > > > symlink
> > > > > > with a fixed name (I have a script called by devd for my
> > > > > > multiple
> > > > > > serial
> > > > > > ports). However, that's not the case with PWM...
> > > > > >
> > > > > > Maybe there is an option to use persistent names for
> > > > > > devices that
> > > > > > somebody
> > > > > > can point to.
> > > > > >
> > > > >
> > > > > Nope, there's no magic thing you're missing that fixes
> > > > > this.  Devices
> > > > > get named-and-numbered based on the order of instantiation.
> > > > >
> > > > > Since what really matters here is the sysctl names, we could
> > > > > change
> > > > > the
> > > > > driver to install the sysctl nodes using the fdt device node
> > > > > names
> > > > > instead of the freebsd newbus device names.  Hmm, actually,
> > > > > since
> > > > > people may be relying on the current names, I guess what we'd
> > > > > have
> > > > > to
> > > > > do is install another set of sysctl names based on fdt name
> > > > > (basically
> > > > > a set of alias names).
> > > > >
> > > > > -- Ian
> > > > >
> > > >
> > > > I see, I agree changing the default naming scheme may damage
> > > > who is
> > > > relaying on it. It is not a good idea. Maybe it could be
> > > > implemented
> > > > in
> > > > release 13.
> > > >
> > > > To Sergey. I used devd in the past, it works well. But i would
> > > > prefer
> > > > not to use it in this case, even if I had a /dev/xyz file
> > > > available.
> > > > The
> > > > reason is that the /dev/xyz file would appear before the the
> > > > devd
> > > > daemon
> > > > starts up (i guess), so the case would not stricly be covered
> > > > by
> > > > what
> > > > the devd man page says devd should do.
> > > > $> man devd
> > > > => " ... Whenever a device is added to or removed from the
> > > > device
> > > > tree ... "
> > > >
> > > > To Ian. The idea of the alias seems good. I don't know at all
> > > > what
> > > > you
> > > > can manage to do at the kernel level with the tunables. I
> > > > imagine
> > > > something like |dev.alias.am335x_ehrpwm.1| which actually
> > > > refers to
> > > > > EHRPWM1| not the second |ehrpwm| that got plugged into the
> > > > > system
> > > > > via
> > > >
> > > > overlay.
> > > >
> > > > Thank you for your answers
> > > >
> > > >
> > >
> > > The dev.* hierarchy is managed by newbus; what I was picturing
> > > was
> > > something like hw.ehrpwm1.freq and so on, settable as either
> > > tunable or
> > > sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
> > > accessible at runtime.  The actual node name is just 'pwm' and
> > > really,
> > > nothing prevents upstream from changing that name on a whim next
> > > time
> > > we import new dts files.  (And linux sure seems to have a lot of
> > > arbitrary whims when it comes to changing dts.)
> >
> >  Relying on the name is clearly not a good idea, especially for TI
> > since they change stuff A LOT.
> >
> > > Since an overlay is required to use this stuff anyway, I'm now
> > > thinking
> > > a custom property in the overlay that names the sysctl nodes
> > > might be a
> > > good option.  So you'd add a property like:
> > >
> > >    &ehrpwm0 {
> > >        status = "okay";
> > >        pinctrl-names = "default";
> > >        pinctrl-0 = <&ehrpwm0_AB_pins>;
> > >        freebsd,sysctl = "backlight";
> > >    };
> > >
> > > And that would make it install names like hw.backlight.freq and
> > > hw.backlight.period and so on.  If you don't add that property,
> > > it just
> > > installs the names it uses now (dev.ehrpwm.*) for compatibility.
> > >
> > > -- Ian
> >
> >  What would be better is to add support to the pwm(9) api for this
> > driver and make the api and pwm(8) using the "pwm-names" property which
> > is a standard one from the bindings.
> >
>
> For this specific case, I think that's great. I'd go farther than say we
> should have the FDT/OFW node name, if any, associated with something like
> dev.<dev>.<unit>.node_name.
>
>

You mean something like this?  :)

dev.imx6_anatop.0.%pnpinfo: name=anatop@20c8000 compat=fsl,imx6q-anatop

That works great if you already know the newbus name and unit and want
to relate it back to fdt.  What we don't have is a way to get back to
the dev.<driver>.<unit>.* oids if all you know is the fdt node name.
Something like

  hw.fdt.xref.<nodename>=<nameunit>

But I suspect the character set for oid names is more constrained than
that of fdt node names.  At least, I've never seen a sysctl name with
an '@' in it before.

-- Ian


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Nicola Mingotti
In reply to this post by Ian Lepore-3


On 6/7/19 7:58 AM, Ian Lepore wrote:

> On Fri, 2019-06-07 at 02:08 -0700, Nicola Mingotti wrote:
>> On 6/6/19 3:40 PM, Ian Lepore wrote:
>>> On Thu, 2019-06-06 at 16:06 -0600, Sergey Manucharian wrote:
>>>> Excerpts from Nicola Mingotti's message from Thu 06-Jun-19 12:33:
>>>>> In my BeagleBone Black, FreeBSD-12 RELEASE, i created two
>>>>> overlays,
>>>>> pwm.dtso and pwm1.dtso. They enable the PWM pins p9.21, p9.22
>>>>> and
>>>>> respectively p9.14, p9.16. DTSO files are below.
>>>>>
>>>>> If I load both the DTBO at boot I see
>>>>> correctly|ehrpwm.0|and|ehrpwm.1|,
>>>>> associated to the correct pins. But, if i remove the
>>>>> overlay|pwm.dtbo|then i seen only|ehrpwm.0|in|sysctl -a|, which
>>>>> is
>>>>> not
>>>>> what i want, i would like to see the name|ehrpwm.1|.
>>>>>
>>>>> This is important because i must be 100% sure a certain pin
>>>>> corresponds
>>>>> the a certain tunable.This must be true even if i remove non
>>>>> relevant
>>>>> overlays in the future. I guess there must be some parameter in
>>>>> the
>>>>> DTSO
>>>>> which i don't know, i hope you can give me some directions
>>>>> about
>>>>> that.
>>>> It is not related to your DTBO's. That's how everything works (at
>>>> least
>>>> by default). You will see the same naming issue with serial
>>>> ports,
>>>> for
>>>> example. And not just in BBB.
>>>>
>>>> E.g. when I have enabled uart0 and uart2 they are named ttyu0 and
>>>> ttyu1,
>>>> if I have only uart2, it becomes ttyu0.
>>>>
>>>> It's easier if there is a device node in /dev, so you can create
>>>> a
>>>> symlink
>>>> with a fixed name (I have a script called by devd for my multiple
>>>> serial
>>>> ports). However, that's not the case with PWM...
>>>>
>>>> Maybe there is an option to use persistent names for devices that
>>>> somebody
>>>> can point to.
>>>>
>>> Nope, there's no magic thing you're missing that fixes
>>> this.  Devices
>>> get named-and-numbered based on the order of instantiation.
>>>
>>> Since what really matters here is the sysctl names, we could change
>>> the
>>> driver to install the sysctl nodes using the fdt device node names
>>> instead of the freebsd newbus device names.  Hmm, actually, since
>>> people may be relying on the current names, I guess what we'd have
>>> to
>>> do is install another set of sysctl names based on fdt name
>>> (basically
>>> a set of alias names).
>>>
>>> -- Ian
>>>
>> I see, I agree changing the default naming scheme may damage who is
>> relaying on it. It is not a good idea. Maybe it could be implemented
>> in
>> release 13.
>>
>> To Sergey. I used devd in the past, it works well. But i would
>> prefer
>> not to use it in this case, even if I had a /dev/xyz file available.
>> The
>> reason is that the /dev/xyz file would appear before the the devd
>> daemon
>> starts up (i guess), so the case would not stricly be covered by
>> what
>> the devd man page says devd should do.
>> $> man devd
>> => " ... Whenever a device is added to or removed from the device
>> tree ... "
>>
>> To Ian. The idea of the alias seems good. I don't know at all what
>> you
>> can manage to do at the kernel level with the tunables. I imagine
>> something like |dev.alias.am335x_ehrpwm.1| which actually refers to
>>> EHRPWM1| not the second |ehrpwm| that got plugged into the system
>>> via
>> overlay.
>>
>> Thank you for your answers
>>
>>
> The dev.* hierarchy is managed by newbus; what I was picturing was
> something like hw.ehrpwm1.freq and so on, settable as either tunable or
> sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
> accessible at runtime.  The actual node name is just 'pwm' and really,
> nothing prevents upstream from changing that name on a whim next time
> we import new dts files.  (And linux sure seems to have a lot of
> arbitrary whims when it comes to changing dts.)
>
> Since an overlay is required to use this stuff anyway, I'm now thinking
> a custom property in the overlay that names the sysctl nodes might be a
> good option.  So you'd add a property like:
>
>     &ehrpwm0 {
>         status = "okay";
>         pinctrl-names = "default";
>         pinctrl-0 = <&ehrpwm0_AB_pins>;
>         freebsd,sysctl = "backlight";
>     };
>
> And that would make it install names like hw.backlight.freq and
> hw.backlight.period and so on.  If you don't add that property, it just
> installs the names it uses now (dev.ehrpwm.*) for compatibility.
>
> -- Ian
>
>

Ian, this |freebsd,sysctl = "foobar"| to me sounds as a very good solution.

In this way I could name the tunable with the "hardware name" or also
with the functional name, as "pwm-motor-front-left". This would improve
the readability of underlying software structure. That would be beautiful.

n.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: How to set PWM tunable name to ehrpwm.1 ?

Ian Lepore-3
On Fri, 2019-06-07 at 10:23 -0700, Nicola Mingotti wrote:

>
> On 6/7/19 7:58 AM, Ian Lepore wrote:
> > [...]
> > >
> > >
> >
> > The dev.* hierarchy is managed by newbus; what I was picturing was
> > something like hw.ehrpwm1.freq and so on, settable as either tunable or
> > sysctl.  But it turns out ehrpwm1 is just a label in the dts, not
> > accessible at runtime.  The actual node name is just 'pwm' and really,
> > nothing prevents upstream from changing that name on a whim next time
> > we import new dts files.  (And linux sure seems to have a lot of
> > arbitrary whims when it comes to changing dts.)
> >
> > Since an overlay is required to use this stuff anyway, I'm now thinking
> > a custom property in the overlay that names the sysctl nodes might be a
> > good option.  So you'd add a property like:
> >
> >     &ehrpwm0 {
> >         status = "okay";
> >         pinctrl-names = "default";
> >         pinctrl-0 = <&ehrpwm0_AB_pins>;
> >         freebsd,sysctl = "backlight";
> >     };
> >
> > And that would make it install names like hw.backlight.freq and
> > hw.backlight.period and so on.  If you don't add that property, it just
> > installs the names it uses now (dev.ehrpwm.*) for compatibility.
> >
> > -- Ian
> >
> >
>
> Ian, this |freebsd,sysctl = "foobar"| to me sounds as a very good solution.
>
> In this way I could name the tunable with the "hardware name" or also
> with the functional name, as "pwm-motor-front-left". This would improve
> the readability of underlying software structure. That would be beautiful.
>
> n.
>

I just realized I never followed up on this thread after doing the
work.

After talking to Manu on irc about this, we decided the right way to go
was to use the pwm(9) kernel api and the pwm(8) userland tool for
controlling pwm devices, instead of just extending the ad-hoc sysctl
scheme in the TI driver.  I reworked the pwm(9) api a bit to support
the idea of "named channels", then added support for pwm(9) to the
ti_ehrpwm driver.  All of that work was done in 13-current and has now
been merged to 12-stable; it should be available in the next weekly-
build snapshots for beaglebone.

To use the new stuff... if you build custom kernels, you can add
'device pwmbus' and 'device pwmc' to your kernel config.  Or, you can
load those devices as modules.  On -current the modules will get auto-
loaded by devd as needed; I'm not sure if that works in 12-stable or
not.  The other thing you need to do is apply a dts overlay to enable
the pwm hardware, setup the pinmux, and define the names for the
channels.  Here's the dtso I used for testing (based on the one you
posted earlier in this thread, but with the freebsd,pwmc nodes added):

/dts-v1/;
/plugin/;

/ {
    compatible = "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
    exclusive-use = "P9.21","P9.22","ehrpwm0_AB";
};

&am33xx_pinmux {
    ehrpwm0_AB_pins: pinmux_ehrpwm0_AB_pins {
        pinctrl-single,pins = <
            0x154 0x03 /* P9.21 */
            0x150 0x03 /* P9.22 */
        >;
    };
};

&ehrpwm0 {
    status = "okay";
    pinctrl-names = "default";
    pinctrl-0 = <&ehrpwm0_AB_pins>;

    pwmcontrol@0 {
        compatible = "freebsd,pwmc";
        reg = <0>;
        label = "backlight";
    };

    pwmcontrol@1 {
        compatible = "freebsd,pwmc";
        reg = <1>;
        label = "ChannelB";
    };
};

&epwmss0 {
    status = "okay";
};

&ecap0 {
    status = "okay";
};

The pwmc(4) driver creates nodes in /dev/pwm/ named pwmcX.Y where X is
the unit number and Y is the channel number within that unit.  As usual
the unit number may change depending on which devices are present, so
the dts can include a label= property and the driver creates an alias
for the pwmcX.Y with that name:

 ll /dev/pwm
 [...] root  wheel       14 Jun 29 13:54 ChannelB@ -> ../pwm/pwmc0.1
 [...] root  wheel       14 Jun 29 13:54 backlight@ -> ../pwm/pwmc0.0
 [...] root  operator  0x5f Jun 29 13:54 pwmc0.0
 [...] root  operator  0x5d Jun 29 13:54 pwmc0.1

With this in place, you can use the pwm(8) tool for control.  It takes
period and duty cycle in nanoseconds, or duty as a percentage.  For
example, to set the 'ChannelB' output to a 100KHz signal with 40% duty
cycle and enable it:

 pwm -f /dev/pwm/ChannelB -E -p 10000 -d 40%

To change it to 1ms on, 1ms off (it stays enabled):

 pwm -f /dev/pwm/ChannelB -p 2000000 -d 1000000

There are manpages for the pwmc(4) device (describes the dts format)
and the pwm(8) tool.  If you are writing your own custom C code for
control, you can use ioctl() calls for pwm control; the pwmc(4) manpage
details that stuff too.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"