Naming of device tree fragments?

[Ken Shirriff]

I need to configure a bunch of pins in a device tree, and I'm unclear of how many fragments I need and how to name them. Specifically, I want the PRU to control some GPIO pins, PRU pins, and PWM pins.

Looking at a typical overlay, it has:

               __overlay__ {

pru_gpio_pins: pinmux_pru_gpio_pins {

pinctrl-single,pins = <

0x1a4 0x0f 

>;

};

pru_pru_pins: pinmux_pru_pru_pins {

pinctrl-single,pins = <

0x1a4 0x25

>;

};

};

In the line "pru_gpio_pins: pinmux_pru_gpio_pins", am I correct that "pru_gpio_pins" is an arbitrary name that gets used in pinctrl-0? What about "pinmux_pru_gpio_pins" - is that arbitrary, or does this need to match something else? (And if it needs to match something, where is that defined?)

Also, do I need to handle GPIO pins and PRU pins separately, as above? Or is that for convenience / convention? And if I want to configure ehrpwm pins, do I need a third section, or can I lump it in with the rest? 

I looked at a bunch of documentation but couldn't find an explanation of this. Instead of randomly cutting-and-pasting, I figured it would be good to get a bit of conceptual understanding so I'm asking here.

Thanks,

Ken

[Robert Nelson]

On Wed, Nov 28, 2018 at 12:08 PM Ken Shirriff <ken.sh...@gmail.com> wrote:
>
> I need to configure a bunch of pins in a device tree, and I'm unclear of how many fragments I need and how to name them. Specifically, I want the PRU to control some GPIO pins, PRU pins, and PWM pins.
>
> Looking at a typical overlay, it has:
> __overlay__ {
> pru_gpio_pins: pinmux_pru_gpio_pins {
> pinctrl-single,pins = <
> 0x1a4 0x0f
> >;
> };
> pru_pru_pins: pinmux_pru_pru_pins {
> pinctrl-single,pins = <
> 0x1a4 0x25
> >;
> };
> };
>
> In the line "pru_gpio_pins: pinmux_pru_gpio_pins", am I correct that "pru_gpio_pins" is an arbitrary name that gets used in pinctrl-0? What about "pinmux_pru_gpio_pins" - is that arbitrary, or does this need to match something else? (And if it needs to match something, where is that defined?)

It's pretty arbitrary, we've just kinda defaulted to the

xyz_pins: pinmux_xyz_pins for awhile now, so it became the
un-documented default..

But there is one change on kernel.org, the second string can't use
"_", so every is defaulting "-".. (there's a dtc warning about it)

pru_gpio_pins: pinmux-pru-gpio-pins

> Also, do I need to handle GPIO pins and PRU pins separately, as above? Or is that for convenience / convention? And if I want to configure ehrpwm pins, do I need a third section, or can I lump it in with the rest?

I'd keep them separate, at one time there was a plan to have a global
list of all pinmux options, but the imx guys found out that just
bloated up the dtb too much, so they removed their's.

Regards,

--
Robert Nelson
https://rcn-ee.com/

[TJF]

Hi!

Why do you think you ...

Am Mittwoch, 28. November 2018 19:08:15 UTC+1 schrieb Ken Shirriff:

... need to configure a bunch of pins in a device tree ...

Instead use libpruio and configure from your source code. (It also provides advanced PWM output at 17 pins, including hardware synchronization of PWMSS.)

Regards

[Ken Shirriff]

Libpruio looks like an interesting library. I thought, though, that the device tree was the "official" way to configure pins. Does libpruio just configure the pin registers directly? Is that "allowed"?

So my question here is if it's okay to configure pins directly through the pinmux registers (either through libpruio or my own code) or if there's a good reason to use device trees. (Personally, I'd rather deal with the registers than with device trees.)

Ken 

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/IczxsQfvQcw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ec0d7196-018b-43da-bd79-17ef41a72fdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[TJF]

Hi Ken!

Am Donnerstag, 29. November 2018 19:16:37 UTC+1 schrieb Ken Shirriff:

Libpruio looks like an interesting library. I thought, though, that the device tree was the "official" way to configure pins.

Libpruio is used in many projects, in university projects, at manufacturer plants or at home. Ie. at my house I use it to control a solar system. Currently it's some kind of insider's tip, since it isn't well supported by the board here.

 

Does libpruio just configure the pin registers directly? Is that "allowed"?

Yes, the LKM configures the Control Module registers directly, fast and reliable. Who allows that you switch on your board? Ask her/him if using libpruio is allowed as well.

So my question here is if it's okay to configure pins directly through the pinmux registers (either through libpruio or my own code) or if there's a good reason to use device trees. (Personally, I'd rather deal with the registers than with device trees.)

The kernel also 'configure pins directly through the pinmux registers', but only during the boot process. Config-pin tool switches pre-defined configurations from user space, without rebooting for every change. And libpruio does the same, but isn't limited to pre-defined values.

Indeed you need not care about pinmuxing at all. Ie. just specify the PWM output you need at a certain pin, and libpruio does the register settings for you (pinmuxing as well as the subsystems hardware registers). When you want to switch to another pin, you can perform by just adapting the pin parameter in your code (single source). All settings are active while your code is running. Finally the destructor restores the system to the original state (like it was befor starting your code - if you don't block that default feature).

Anyway, I recommend to use a very simple device tree blob in order to just claim the used pins, so that other software will not disturb your configurations. But that is optional and can be done later when your PCB is burned.

Check some examples and see what I mean. Since version 0.6 it has an inbuild PRU driver to run firmware on the other PRU.

Regards