Device tree - reclaiming resources.

So, I’m wondering with a hardware resource, that is “claimed” through the main board device tree file. Such as the on board USR LEDs. What is the proper way to reclaim these pins, so they can be used for a different purpose ?

So, I'm wondering with a hardware resource, that is "claimed" through the
main board device tree file. Such as the on board USR LEDs. What is the
proper way to reclaim these pins, so they can be used for a different
purpose ?

They are claimed here:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bone-common.dtsi#n21

via:

pinctrl-0 = <&user_leds_s0>;
&
gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;
gpios = <&gpio1 22 GPIO_ACTIVE_HIGH>;
gpios = <&gpio1 23 GPIO_ACTIVE_HIGH>;
gpios = <&gpio1 24 GPIO_ACTIVE_HIGH>;

Whereas this define, doesn't 'claim' them, it just set's up a struct
to be utiilzed by above ^^

user_leds_s0: user_leds_s0 {
        pinctrl-single,pins = <
                 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a5.gpio1_21 */
                0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_a6.gpio1_22 */
                0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* gpmc_a7.gpio1_23 */
                0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* gpmc_a8.gpio1_24 */
        >;
};

Regards,

Hello Robert,

Thanks for the reply. Essentially, I’ve been looking through all of that for the last week or so ( off an on ). I Kind of got stuck on stuff like this:

gpios = <&gpio1 21 GPIO_ACTIVE_HIGH>;

Ok, so this whole line makes complete sense to me, except the variable that is being assigned. I have not been able to find any information on this yet. Somewhere there was a mention to the gpio.h header file, but that file only has two defines that can not possibly tell me what the variable “gpios” is.

My end goal however is just to use the USR LEDs, but I want explicit control of the LEDs for my app, so Linux is not “confused”. At the same time, I was hoping to avoid changing stock files if at all possible.

Is this possible, or will I have to modify the board files no matter what ?

You can override them thru userspace:

usr0: for example:

debian@test-bbb-3:/sys/class/leds/beaglebone:green:usr0$ cat trigger
none nand-disk usb-gadget usb-host mmc0 mmc1 timer oneshot [heartbeat]
backlight gpio cpu0 default-on
debian@test-bbb-3:/sys/class/leds/beaglebone:green:usr0$ cat brightness
0
debian@test-bbb-3:/sys/class/leds/beaglebone:green:usr0$ cat brightness
255

Change trigger to 'none' and just switch the brightness from 0 <-> 255
for on/off

Regards,

You can override them thru userspace:

usr0: for example:

*debian@test-bbb-3:/sys/class/*leds/beaglebone:green:usr0$ cat trigger
none nand-disk usb-gadget usb-host mmc0 mmc1 timer oneshot [heartbeat]
backlight gpio cpu0 default-on
*debian@test-bbb-3:/sys/class/*leds/beaglebone:green:usr0$ cat brightness
0
*debian@test-bbb-3:/sys/class/*leds/beaglebone:green:usr0$ cat brightness
255

Change trigger to ‘none’ and just switch the brightness from 0 <-> 255
for on/off

Ok that I knew of, just was not sure if that was the proper way to do things. I also read an old Dr. Dobbs article where you can echo “gpio_leds” to some unbind file in the debugfs file structure I think it was.

Where I’m going with this though is that I want to setup a UIO “driver” using the USR LEDs as a simple UIO example for others to read. In fact, I’m still learning much of this myself but . . . heh

Ok, so after toying around a bit, I guess my above proposal is / would be a bad example of how to use uio. In fact, I’m starting to think it is “impossible” without hacking up a special driver, and changing a few default files. It’s pretty bad, when the light at the end of the tunnel, seems to point to using uio_pruss . . . which actually makes a whole lot more sense I suppose.

The LEDs are kind of a special case. When I was working on the
universal overlay, I wanted to be able to make the LEDs available at
run-time like I do with most of the other pins, but it just doesn't
really work out that way. Since the kernel LED driver has to bind to
the GPIO, there's no way (that I know of or found digging through the
code) to "unbind" the GPIO from the kernel LED driver. The rest of
the universal overlay simply uses a pinmux helper to allow switching
between different functions (like GPIO, SPI, PWM, etc). It doesn't
allow multiple kernel functions (like user GPIO and the kernel LED
driver) to bind to the same GPIO pin.

This might be possible now with the 4.x kernels and device tree
changesets, but I haven't tried. In theory it might work on 3.8 if
you made each LED it's own "cape", so you'd unload the LED cape to
restore user access to the GPIO pin, but unloading device trees in 3.8
is mostly a handy way to crash the kernel. :-/

Hi Charles,

Well, one can always mmap() /dev/mem/ @ 0x4804C000, but I was kind of hoping to avoid that. When all is said and done, for an example to learn by, and share with others. I think using uio_pruss, and some sort of shared memory “scheme” would be “better” than using /dev/mem/. As I think that perhaps exposing the whole gpio1 bank to userspace, just to get at the USR LEDs, is probably not the greatest idea. At least with uio_pruss, I can write PRU code that just reads from the shared memory, and twiddle the USR LEDs based on a small ( nibble ) bit field.

It’s pretty awesome how flexible uio_pruss really can be, when you think about it a bit.