Naming of device tree fragments?

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

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,

Hi!

Why do you think you …

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

Hi Ken!

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