[U-Boot] [PATCH v3 1/3] Tegra: fdt: Add/enhance sdhci (mmc) nodes for all T20 DT files

[Lucas Stach <dev@lynxeye.de>]

Am Donnerstag, den 14.02.2013, 13:24 -0700 schrieb Stephen Warren:
[...]
> >>
> >> The one issue with this is that only newer versions of dtc support the
> >> -i option. The version packaged with most distros won't support it.
> >> That'll mean something like "MAKEALL -a arm" is going to fail for a lot
> >> of people without some kind of explicit action (i.e. manually installing
> >> a newer version of dtc).
> >>
> >> That's why I suggested switching from /include/ to #include, and adding
> >> the include path to the cpp command rather than dtc.
> >
> > I tried using '#include, and added the 2 dts paths to the DTS_CPPFLAGS
> > so gcc could find the files, but I got a 'couldn't open
> > 'skeleton.dtsi' error. I didn't want to change tegra20.dtsi to
> > #include "skeleton.dtsi', and all the other board dts files to
> > #include ARCH_CPU_DTS, just so we can support the common tamonten
> > dtsi, so I went back to the DTC include path changes.
> 
> I think that's exactly where we should end up though. It's certainly the
> way the kernel is also heading.
> 
> Right now, the Avionic Design boards might be the only place this
> problem crops up, but as we support more features on Cardhu, we'll hit
> exactly the same issue, so have to solve it there too.
> 
Right now the AD boards might be the only ones with this problem, but it
will certainly hit the Toradex Tegra designs also.

I'm planning on doing support for the Colibri Evaluation Carrier for the
next release cycle. So I need to split up the DTS between Colibri and
Carrier board, same as is done in the Linux Kernel dts.
> > There was talk at one time of putting an up-to-date DTC binary in the
> > U-Boot tools area so everyone would have a consistent level of DT
> > support.
> 
> I think Wolfgang nak'd that.
> 
>  With the small number of boards using DT at this time, I
> > think we can live with letting people know where to find the latest
> > DTC release until then.
> 
> But he also nak'd the idea of relying on a newer dtc:-(
> 
> I think we had better raise the question again.

Yes, this has to be resolved one way or the other.