How to set PWM tunable name to ehrpwm.1 ?
Bernd Walter
ticso at cicely7.cicely.de
Fri Jun 7 11:33:01 UTC 2019
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 at 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 <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
More information about the freebsd-arm
mailing list