Re: [PATCH v2] ARM: dts: am335x-bone-common: Add i2c2 definition

[Matt Porter]

On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
> On Tue, May 13, 2014 at 2:53 PM, Tom Rini <trini@xxxxxx> wrote:
> > On 05/12/2014 04:57 PM, Robert Nelson wrote:
> >>>> Either case if fine with me.  As who knows when the dtc "overlay" will
> >>>> every truly make it mainline, as the capemgr was the only real kernel
> >>>> user of the i2c/at24 eeprom information.
> >>>
> >>> Sounds like we should keep it disabled though so u-boot can be used
> >>> to toggle it while waiting for the capemgr. That's because the board
> >>> has a header for pins, so it's not exactly limited to just the capes.
> >>>
> >>> Anybody working on enabling/disabling cape dtb configurations in u-boot?
> >>
> >> Well,
> >>
> >> Would Tom even approve of that in mainline u-boot? He didn't want my
> >> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
> >>
> >> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
> >>
> >> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
> 
> Using fdt set from the bootloader to use the same FDT for similar
> boards (like the example with Beagle xM variants) is kind of trying to
> replicate what we used to do from boards files where it was possible
> to manage a set of boards using the same platform code.
> 
> But Device Trees are meant to describe hardware and thus should be
> static, if two board are almost identical but slightly different, then
> are two different hardware where each need its proper FDT that
> describes it.
> 
> >
> > I would think that using the 'fdt' command in U-Boot to add all
> > properties of every cape found on a running system would drive someone
> > to madness quite quickly.  Moving all of Pantelis' work for dynamic
> > device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
> > etc) sounds like a step in the wrong direction.
> >
> 
> Agreed. I think that until the device tree overlay and the cape
> manager find their way into mainline we should treat capes as if they
> were expansion boards attached to a Computer-on-Module. That is, a
> static based board which its own DTS including the BB{B,W} as an dtsi
> and not something that can be added on runtime.

It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.

-Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/