Well, at least part of the mystery seems to have been solved. For some
reason the GPIO numbers for export are offset by 32. So, *gpio_138* is
actually *gpio-170* in the 3.11 kernel.
root@arm:~# echo 170 > /sys/class/gpio/export
root@arm:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, gpio:
GPIOs 32-63, gpio:
GPIOs 64-95, gpio:
GPIOs 96-127, gpio:
GPIOs 128-159, gpio:
gpio-132 (user ) in lo
GPIOs 160-191, gpio:
gpio-170 (sysfs ) in lo
gpio-179 (hsusb2_phy.25 ) out hi
GPIOs 492-511, platform/gpio.38, twl4030, can sleep:
gpio-510 (hsusb2_vbus ) out hi
root@arm:~# echo "high" > /sys/class/gpio/gpio170/direction - the LED
lights up!
root@arm:~# cat /sys/kernel/debug/gpio
GPIOs 0-31, gpio:
GPIOs 32-63, gpio:
GPIOs 64-95, gpio:
GPIOs 96-127, gpio:
GPIOs 128-159, gpio:
gpio-132 (user ) in lo
GPIOs 160-191, gpio:
gpio-170 (sysfs ) out hi
gpio-179 (hsusb2_phy.25 ) out hi
GPIOs 492-511, platform/gpio.38, twl4030, can sleep:
gpio-510 (hsusb2_vbus ) out hi
I don't understand where this offset is coming from (unless somehow the
first 32 GPIOs are counted twice - once on the CORE Control Module, and
once on the Wkup Control Module?).
Also, it is very strange that the Core pinmux register value display
crashes, so we cannot verify the pins are muxed the way we need them to.
On Thursday, October 31, 2013 4:13:58 PM UTC-4, porkupan wrote:
>
> Well, so I think I understand a bit more about the DTS support for GPIO.
> I configured the pinctrl for GPIO5 channel, and it seems to have some
> effect on the GPIO pins. After the kernel starts up the LEDs are being
> turned off.
>
> &omap3_pmx_core {
> vvv_gpio_pins: pinmux_gpio_pins {
> pinctrl-single,pins = <
> 0x136 (PIN_OUTPUT | MUX_MODE4) /*
> gpio_137 */
> 0x138 (PIN_OUTPUT | MUX_MODE4) /*
> gpio_138 */
> 0x13a (PIN_OUTPUT | MUX_MODE4) /*
> gpio_139 */
> >;
> };
> };
>
> &gpio5 {
> pinctrl-names = "default";
> pinctrl-0 = <&vvv_gpio_pins>;
> };
>
> However the GPIO export mechanism from userspace is still not working.
> Basically, no matter what value you try to set gpio137-139, they stay low
> (although the value in the /sys/class/gpio/gpioXXX/value file is being
> changed appropriately. It's as if gpiochip128 is not really associated
> with gpio5.
>
> I am also worried about not being able to dump *
> /sys/kernel/debug/pinctrl/48002030.pinmux/pins* . The kernel hiccup
> occurs on the base 3.11 DTB file, so it's not my change that's causing it.
>
>
>
> On Friday, October 25, 2013 3:13:46 PM UTC-4, porkupan wrote:
>>
>> Trying to dump the pinmux states
>> (/sys/kernel/debug/pinctrl/48002030.pinmux/pins) in 3.11 seems to cause a
>> kernel crash:
>> http://paste.ubuntu.com/6302171/
>>
>> GPIO access via /sys/class/gpio appears to be nonoperational in 3.11.
>> It looks like a reasonable assumption that GPIOs may not be muxed into the
>> GPIO pins.
>>
>> I tried to add a devicetree entry to to force-mux GPIOs:
>>
>> &omap3_pmx_core {
>> vvv_gpio_pins: pinmux_gpio_pins {
>> pinctrl-single,pins = <
>> 0x134 (PIN_OUTPUT | MUX_MODE4) /*
>> gpio_137 */
>> 0x135 (PIN_OUTPUT | MUX_MODE4) /*
>> gpio_138 */
>> 0x136 (PIN_OUTPUT | MUX_MODE4) /*
>> gpio_139 */
>> >;
>> };
>> };
>>
>> &ocp {
>> gpio_helper: helper {
>> compatible = "ti,omap3-gpio";
>> pinctrl-names = "default";
>> pinctrl-0 = <&vvv_gpio_pins>;
>> status = "okay";
>> };
>> };
>>
>> Doesn't seem to do anything. The only indication that the kernel is
>> actually trying to parse the fake "helper" device is these lines in the
>> message log:
>>
>> [ 0.369201] omap_gpio helper.26: could not find pctldev for node
>> /ocp/pinmux@48002030/pinmux_gpio_pins, deferring probe
>> [ 0.369232] platform helper.26: Driver omap_gpio requests probe deferral
>> <...>
>> [ 3.354125] omap_gpio helper.26: Invalid IRQ resource
>>
>> Obviously, I have no idea what "compatible" driver should I chose,
>> omap3_gpio just sounded like something that could fit. For BBB they
>> reference bone-pinmux-helper, which I assume is BBB-specific?
>>
>> Thanks!
>>
>>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
