On 9/16/2014 10:26 AM, Robert Nelson wrote:
>
> NM, found a work around..
>
> When we "know" what cape is installed, thus we are already building a
> *.dtb for it, just disable the pinmux, as it's already tied to the
> cape.
>
> diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> index 2df34ce..138a619 100644
> --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
> @@ -6,6 +6,12 @@
> * published by the Free Software Foundation.
> */
>
> +&ocp {
> + P9_27_pinmux {
> + status = "disabled";
> + };
> +};
> +
> &lcdc {
> status = "okay";
> };
Yes, that's what you need to do for now, and this is why no "cape" pins
can be controlled at run-time without using a device-tree overlay (or
changeset).
What I'm working on is adding a setting to the pinmux helper, so rather
than trying to have the LCD cape "own" the pinmux setting, it would just
let the pinmux helper know it should start in a specific mode.
...but it looks like you might be assigning LEDs to the GPIO. This
causes the GPIO pin to be "owned" by the gpio-leds driver, making it
impossible to use the pin as a GPIO for any other purpose. I haven't
worked out a solution for this, other than to not use the kernel
gpio-leds driver (driving the LED from userspace) or just give up the
option to reconfigure the I/O and let the kernel LED driver "own" it.
--
Charles Steinkuehler
[email protected]
--
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/d/optout.
