How to set PWM tunable name to ehrpwm.1 ?

Ian Lepore ian at freebsd.org
Fri Jun 7 14:58:59 UTC 2019


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




More information about the freebsd-arm mailing list