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.

-- 
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.

Reply via email to