How to set PWM tunable name to ehrpwm.1 ?
Nicola Mingotti
nmingotti at gmail.com
Fri Jun 7 17:23:15 UTC 2019
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.
More information about the freebsd-arm
mailing list