Problem setting some pinmuxes with Device Tree Overlay

I’m using a BeagleBone White (Rev A5) for cape development. I have installed an official Angstrom image with Linux 3.8.13 from June 5th.

I am assigning 32 pins as GPIO with a dts overlay. The cape is found at boot and the driver loads successfully:

root@beaglebone:~# cat /sys/devices/bone_capemgr.7/slots 0: 54:P---L IndustrialCape,00A0,My Company,P70626 1: 55:PF--- 2: 56:PF--- 3: 57:PF---

The problem is that some of the pins, that I have assigned as GPIO outputs, do not have the correct pinmux:

root@beaglebone:~# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins registered pins: 142 pin 0 (44e10800) 00000031 pinctrl-single pin 1 (44e10804) 00000031 pinctrl-single pin 2 (44e10808) 00000031 pinctrl-single pin 3 (44e1080c) 00000031 pinctrl-single pin 4 (44e10810) 00000027 pinctrl-single ....

These first 4 pins are mapped to BB GPIO_32, 33, 34, and 35 (processor GPIO1_0, 1, 2, and 3). A check of the gpio list doesn’t show anything other than my sysfs mappings controlling the related GPIO:

root@beaglebone:~# cat /sys/kernel/debug/gpio .... GPIOs 32-63, gpio: gpio-32 (sysfs ) out lo gpio-33 (sysfs ) out lo gpio-34 (sysfs ) out hi gpio-35 (sysfs ) out hi ....

I know these pins are used for MMC1 on the BBB, I wanted to make my cape BBB compatible, but I used the wrong MMC1 mux when I designed it. These will be fixed on the next hardware version, but I would like to verify the rest of the board before I commit to a new PCB. Which is why I am using a BBW for prototyping.

But am I missing something? Are these pins somehow being reserved for MMC1 or are the pinmuxes getting overwritten after real capes are enumerated?

Thanks,
Louis

I'm using a BeagleBone White (Rev A5) for cape development. I have
installed an official Angstrom image with Linux 3.8.13 from June
5th.

I am assigning 32 pins as GPIO with a dts overlay. The cape is
found at boot and the driver loads successfully:

root@beaglebone:~# cat /sys/devices/bone_capemgr.7/slots 0:
54:P---L IndustrialCape,00A0,My Company,P70626 1: 55:PF--- 2:
56:PF--- 3: 57:PF---

The problem is that some of the pins, that I have assigned as GPIO
outputs, do not have the correct pinmux:

<snip>

But am I missing something? Are these pins somehow being reserved
for MMC1 or are the pinmuxes getting overwritten after real capes
are enumerated?

What's your dts file look like?

- --
Charles Steinkuehler
charles@steinkuehler.net

I almost included it on the first post, but didn’t want “too much info” in the post…here it is…

`
/*

I have done some more testing.

I compared the output of

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins

with and without the cape attached. I can verify that pinmuxes for pins 16,18,19, 100,101,102,103,105,107, and 109 all change from 0x027 to 0x037. This doesn’t really matter though, because they go from GPIO mode to GPIO mode. However, pins 86 and 87 change from I2C1 (0x62) mode to GPIO (0x037) mode, so I know that my overlay is doing something to the pinmux registers*.*

Louis

I think I found a solution. By running:

root@beaglebone:~# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins

I was able to determine that the mux was only being claimed for the first block (digital inputs). I tried separating the <&ocp> fragment into three blocks, one for inputs, one for outputs, and one for serial, but that didn’t work. I then combined the output muxes with the input muxes (in “digital_input_pins: pinmux_di_pins {}”) and I was able to see all input and output muxes being controlled by “tester_pinmux_helper.9” (by repeating the cat call above).

A call to:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins
verifies that the pin muxes are set properly now.

So, for some reason the syntax of my “digital_output_pins: pinmux_do_pins” block is not being read properly, yet there are no warnings or failures to load the driver. I would like to know what is wrong with the syntax, but at least I have a way to get it working.

Thanks,
Louis