Device Tree Overlay pinmux modification doe not modify the physical pin or the file interface values

GoogleGroups
1

The changes I make to the pinmux in the Device Tree Overlay are not reflected when I read the files in /sys/class/gpio or probe the physical pin itself. However, the change IS reflected when I read /sys/kernel/debug/pinctrl/44e10800.pinmux/pins. The OS is the Rev C Debian build.

Setting the Pin to an input w/ a pulldown:
-In my Device Tree Overlay file, I set GPIO pin P9_15(referred to as 48 by the kernel and having offset address 0x040) to be an input pin with a pulldown resistor(register value 0x27).
-I echo the appropriate overlay to ‘/sys/devices/bone_capemgr.9/slots’
-When when I do a 'cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep ‘840’ ’ , I get ‘pin 16 (44e10840) 00000027 pinctrl-single’. This indicates that the pin is correctly set as an input and with a pulldown resistor.
-When I do ‘cat value’ in the gpio48 directory, I get 1. I should get a 0 since the pulldown is enabled.

Setting the pin to an output:

-In my Device Tree Overlay file, I set GPIO pin P9_15(referred to as 48 by the kernel and having offset address 0x040) to be an output pin (register value 0x07).
-I echo the appropriate overlay to ‘/sys/devices/bone_capemgr.9/slots’

-When when I do a 'cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep ‘840’ ’ , I get ‘pin 16 (44e10840) 00000007 pinctrl-single’. This indicates that the pin is correctly set as an output.
-When I do ‘cat direction’ in the gpio48 directory, I get ‘in’. I should get ‘out’ since the pin is set as an output.

If I manually set the direction,value, etc… by echoing to the file interfaces, then everything works perfectly.

Should modifications in the DTO reflect in the file interfaces and on the physical pin itself, or is my understanding incorrect? Derek Molloy encounters this same issue in his GPIO video (https://www.youtube.com/watch?v=wui_wU1AeQc @31:00).

Thanks!
Michael

FYI, here is one of the DTOs:

/*

2

Hi Michael

When I do ‘cat value’ in the gpio48 directory, I get 1. I should get a 0 since the pulldown is enabled.

To my experience the ‘cat value’ not always reflects actual level on the wire.

and

Should modifications in the DTO reflect in the file interfaces and on the physical pin itself,

DTO modifications not always change the pinmux settings or pin state. (For example uEnv.txt settings might override them)

I concluded useless to study roots of every case, as well as got tired from checking pinmux settings and wire levels every time I connect new device to the system, and wrote small linux utility showing the punmux settings, GPIO configurations, and wire levels(if GPIO receiver enabled).
Maybe it will be helpful in your case, to understand what is where: www.academ.org/~sv/epc/pinmux.pdf

Serge

3

Thanks for the info Serge!

I did some more tests, and it looks like applying the DTO will set some parameters of the pin, but not others. You always need to manually set the state using the files in order to get a guaranteed state. For example, let’s say that I set a pin to be an Input w/ a pullup using the DTO. The actual pin may still be set to an output. But if I manually set the pin as an input using “direction” file, then the input pin will read high due to the pullup set in the DTO. Similarly… if a pin is set w/ a pulldown in the DTO, then the actual pin will read low only when you switch it to an input using the “direction” file.

It seems strange that a pin set as an input in the DTO could be set as an output using the files(and vice versa), but I guess that’s just how it works. Need to be very careful to avoid inconsistent pin states.