GPIO sysfs 'direction' broken

hi all,

in 3.2.* kernels, by default the ‘direction’ file /sys/class/gpio/gpioN/direction is writable but has no effect. this is because the pin is muxed to mode OMAP_PIN_OUTPUT when it should be OMAP_INPUT_EN. this is true with ubuntu 12.04 with a stock 3.2.0-23-omap kernel, and also RCN-EE’s 3.2.16 stable kernel.

asking on IRC, ‘Russ’ and ‘mdp’ were helpful in pointing me toward /sys/kernel/debug/omap_mux/mcbsp1_fsr : namely, i have to write 0x104 to this file to put it into OMAP_INPUT_IN with mode 4 (0x104 = (1<<8)|4) in order to make ‘direction’ work for GPIO 157.

it seems that the mux mode should default to OMAP_INPUT_EN either in board-omap3beagle or in u-boot. is there somewhere i should file a bug/report about this? it breaks all of the online how-tos and tutorials about how to use GPIO.


Hi Damian,

I am also new to the community, however I have been playing with pin muxing for over a year now, fun and frustrating at the same time.

You can play around with this stuff, however if you think about its not really a bug, the pin is mapped so that it is not an input pin. is a tool provided by ti to define the pinmux of your own choosing and then you can do what ever you like with it.

We have used the files the above tool generates in u-boot, that way we don’t have to re-compile the kernel each time, we simply re-compile u-boot and the way we go.

Just a word of caution, to ensure the processor is not drawing a large amount of current, do leave unused gpio’s in a dormant (or protected) mode or you can go through and make sure the pin-fan-out is done correctly.

Hope this helps


hi Husain,

thanks, i didn’t know about the dormant GPIOs drawing more current! this makes sense. apparently a proper pin manager is expected in the kernel soon, so i guess we’ll wait for that.


Hi Damian,

The way I look at it, its not really too difficult, infect a tool similar to the GUI firewall builder in Linux can be made to simplify this stuff or even a CSV file, Even the mux.h file in u-boot can be made into various defines that are changed by the likes of menuconfig, xconfig. Only issue is time,

A similar function can be adapted to change stuff in real-time through user space

You are absolutely correct in waiting for such an interface, only question is, why was it not made available earlier.