On Tue, Sep 16, 2014 at 6:06 PM, Charles Steinkuehler <[email protected]> wrote: > On 9/16/2014 4:55 PM, Joshua Datko wrote: >> >> I've been trying to follow along with these changes and I admit, I >> haven't been able to keep up. >> >> Some questions: >> >> 1. My Cape DTS does not explicitly call out for i2c2 [1], with this >> change does that, and all capes using i2c2, need to be fixed? > > The i2c2 is typically defined by the base BeagleBone device tree (or > more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest > device trees for 3.14). The cape dtsi files (or overly files for 3.8) > generally only include things that need to be changed to support the > cape, so unless you were intentionally trying to modify the i2c2 > hardware, you wouldn't reference it in you cape file. > > Your cape file simply adds some target entries for the i2c2 bus, which > would work as expected and need no changes regardless of whether the > i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the > device tree compiler will merge the main i2c2 definitions with your > additions). By way of similar example, you're also not specifying the > base address of the i2c2 hardware, the interrupt(s) it uses, etc, but > that all works since it's pulled in from common dts files before your > cape file is included. > >> 2. Is the default mode of pins P_19/20, once user space is reached, GPIO >> or i2c2? > > The purpose of this change is to allow the pinmux-helper to be in > control of the pin, but have it come up in the desired mode (i2c in this > case) instead of the default gpio mode, which is what would have > happened previously.
Just going along to state the obvious... eMMC and HDMI will be equally interesting tests and more practically useful for more capes. It will only be a matter of time before someone damages a board by: A) setting an HDMI pin to a output without disabling the HDMI B) driving an eMMC pin into conflict without putting the eMMC in reset I don't think there is a simple way for the current pinmux helper to check for these conditions, but it wouldn't hurt if any config-pin sort of utility would check the state of those hardware control bits before helping someone screw things up. :-) Any way you can imagine a way to keep the current uEnv.txt lines to disable both of those working without breaking compatibility? > > -- > 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.
