# How to find who occupies pin X in Device Tree?

I've already learned how to find which pins can be assigned to a functionality I just open the [arch]-pinfunc.h file and find the entries after __ for given functionality and then find the pin that provides it, left of the __ in the entry. Then I just write the right entry in .dts/.dtsi referencing the pin identity in a way specific to that entry.

But the worse problem is if the pin is already assigned - conflicting with my purpose - and I don't know what to. Not such a big problem if it's a default described in the datasheets, worse if it's an obscure helper functionality left over from development, and not even routed to the board so I won't find it in the schematics. The device tree for modern processors is extensive and long and normally I'd need to check every single entry (out of a couple hundred) to see if any uses the pin I want.

Is there any easier/simpler way to find what functionality is currently assigned to given pin in .dts?

• Which hardware platform? Which kernel version?
– kdopen
Jul 29 '15 at 14:17
• 3.10 and later; the answer really should be platform-agnostic, that's what Device Tree is all about, but if it's needed, I.MX6
– SF.
Jul 29 '15 at 15:39

Possible Solution
The most simple way to find this is a simple text search through the *.dts file for the pin name. You may be able to look at some random pin in the *.dts file and compare it to the schematic to see the naming scheme to give you an idea of what it should look like.

For example, if the the schematic has a GPIO Pin3 on Port A, you might see something like "gpio_portA-3" or some other permutation. Look for a pin in the *.dts file that also appears in the schematic to identify the naming pattern.

Once you have that, search for the pin you're actually interested in. If you don't find it right away, try different variations, and perhaps try regular expressions to match varying separating characters. If you find it, you should be able to see what the parent node is, which will tell you what the pin does.

Given this poor guy's adventures with reverse-engineering the BeagleBone Black's pinmux mappings, you should consider yourself lucky if a simple text search actually works for you.

Caveat
Unfortunately, there's no guarantee that the pin you're interested in will even be present in the FDT. If a pin doesn't require direct interaction from the OS to work properly, it won't be there. Consider this example from devicetree.org:

/ {
#size-cells = <1>;

...

serial@101f0000 {
compatible = "arm,pl011";
reg = <0x101f0000 0x1000 >;
};

serial@101f2000 {
compatible = "arm,pl011";
reg = <0x101f2000 0x1000 >;
};

gpio@101f3000 {
compatible = "arm,pl061";
reg = <0x101f3000 0x1000
0x101f4000 0x0010>;
};

interrupt-controller@10140000 {
compatible = "arm,pl190";
reg = <0x10140000 0x1000 >;
};

spi@10115000 {
compatible = "arm,pl022";
reg = <0x10115000 0x1000 >;
};

...

};


This block describes a couple of memory-mapped devices, including serial, SPI, and interrupt controllers, and even GPIOs. All of those, with the possible exception of the interrupt controller, must use pins, yet they aren't specifically present here. This is because the manipulation of the pins is intended to be done by hardware, and the OS shouldn't have to know or care which pins are used. All the OS needs to know is how to interact with the controllers' registers, so the pin information may be left out of the FDT.

If your kernel is compiled with debugfs support (CONFIG_DEBUG_FS), then often you can use debugfs to inspect pinctrl mappings at runtime.

$mount -t debugfs none /sys/kernel/debug # ensure debugfs is mounted$ cat /sys/kernel/debug/pinctrl/pinctrl-maps  # prints info on pin mappings


Not strictly related, but also useful:

\$ cat /sys/kernel/debug/gpio     # prints configuration and state of GPIO lines


Debugging tools such as devmem2 are also very helpful as you can often use this to quickly inspect the value of the registers that control configuration of each pin.