I've been trying out http://builds.beagleboard.org/builders/runtests/builds/39 that seems to have several of these changes implemented...
On Tue, Sep 16, 2014 at 11:55 AM, Charles Steinkuehler <[email protected]> wrote: > 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. In general, I prefer leaving the pinmux helper in control, but I think *some* of the lines might be *ok* to put under control of the LCD, no? > > ...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. For normalcy, do we agree then to put everything possible into a pinmux helper and simply impact the boot-up state of the helper? I see one conflict here that needs to be resolved: [ 12.785659] pinctrl-single 44e10800.pinmux: pin 44e109ac.0 already requested by P9_25_pinmux.30; cannot claim for 48038000.mcasp [ 12.798203] pinctrl-single 44e10800.pinmux: pin-107 (48038000.mcasp) status -22 [ 12.806053] pinctrl-single 44e10800.pinmux: could not request pin 107 (44e109ac.0) from group mcasp0_pins on device pinctrl-single [ 12.818665] davinci-mcasp 48038000.mcasp: Error applying setting, reverse things back Any idea why there isn't a status entry on the cape-universal node? root@beaglebone:~# ls /sys/devices/ocp.3/cape-universal.41/ modalias power subsystem uevent Full boot log: http://pastebin.com/JJkRic8h BTW, this build seems to have resolved the funny P9_14 issue being associated with the uSD card. > > -- > 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. -- 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.
