Maybe somewhat off topic, however I cannot help but to ask this; "How can we disable HDMI in kernel version >= 3.14?" where we do not have capemgr?
On Wed, Sep 17, 2014 at 7:37 AM, Jason Kridner <[email protected]> wrote: > 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. > -- 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.
