Date: Fri, 07 Jun 2019 09:27:01 -0600 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, Emmanuel Vadot <manu@bidouilliste.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: How to set PWM tunable name to ehrpwm.1 ? Message-ID: <53f74173b7b2de820d16d3bb750001cfc026a179.camel@freebsd.org> In-Reply-To: <CANCZdfqYrKRS9ecUknKZHpXPnGM=XWSLVxObDy-fGD5-ptSP3Q@mail.gmail.com> References: <68790975-a5a5-2138-ca89-117878d6cf2d@gmail.com> <20190606220639.GE13546@eldorado> <8126fa4ae0ca650ca12f28dd538e6e8c4e81b432.camel@freebsd.org> <2852b9da-e647-69a7-3218-88cfa500eadc@gmail.com> <ee540fb38eca660a722f561fc91b660560133ed5.camel@freebsd.org> <20190607171001.636efb2598ab9c88635973b6@bidouilliste.com> <CANCZdfqYrKRS9ecUknKZHpXPnGM=XWSLVxObDy-fGD5-ptSP3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2019-06-07 at 09:17 -0600, Warner Losh wrote:
> On Fri, Jun 7, 2019 at 9:11 AM Emmanuel Vadot <manu@bidouilliste.com>
> wrote:
>
> > On Fri, 07 Jun 2019 08:58:49 -0600
> > Ian Lepore <ian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53f74173b7b2de820d16d3bb750001cfc026a179.camel>