There appear to be two pinmux ranges: 48002030.pinmux 48002a00.pinmux Dumping /sys/kernel/debug/pinctrl/48002030.pinmux/pins crashes the kernel; and GPIO_137 seems to be muxed via 0x48002164, so I cannot see what is muxed on that pin. Dumping /sys/kernel/debug/pinctrl/48002a00.pinmux/pins seems to produce valid output, but I am not sure it is of any use to me.
On Thursday, October 24, 2013 3:42:06 PM UTC-4, RobertCNelson wrote: > > On Thu, Oct 24, 2013 at 2:32 PM, porkupan <[email protected]<javascript:>> > wrote: > > Well, then how do we make sure the GPIOs are muxed on the pins? The > > "normal" way to access GPIOs (via /sys/class/gpio) is not working in > 3.11. > > Maybe due to the multiplexing? It worked fine in 3.7 stable, if it's > any > > help. > > Well, with 3.7 we did not use device tree's... > > > /sys/kernel/debug/omap_mux is present, but it's empty. It is > configured in > > the kernel build. I don't see how it can be enabled in device tree. > > It's not a "device tree" only zImage, as a few board files are still > enabled that do not work with very well with device trees.. > > the "TI" only "omap_mux" has been replaced by the generic "pinctrl" > driver.. > > See: > /sys/kernel/debug/pinctrl/44e10800.pinmux/pins > > Regards, > > -- > Robert Nelson > http://www.rcn-ee.com/ > -- 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.
