[U-Boot] [PATCH 2/7] tegra: fdt: Add extra I2C definitions for U-Boot

[Simon Glass <sjg@chromium.org>]

Hi Stephen,

On Dec 28, 2011 10:40 PM, "Stephen Warren" <swarren@nvidia.com> wrote:
>
> Simon Glass wrote at Monday, December 26, 2011 10:15 PM:
> > On Mon, Dec 26, 2011 at 8:35 PM, Stephen Warren <swarren@nvidia.com>
wrote:
> > > Simon Glass wrote at Monday, December 26, 2011 11:12 AM:
> > >> Add U-Boot's peripheral ID and pinmux selection to the Tegra20
> > >> device tree file.
> > >
> > >> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
> > > ...
> > >>               compatible = "nvidia,tegra20-i2c";
> > >>               reg = <0x7000C000 0x100>;
> > >>               interrupts = < 70 >;
> > >> +             u-boot,pinmux = <0>;
> > >
> > > That isn't acceptable to me for the same reasons I've outline many
> > > times before while discussing USB.
> > >
> > > At least periph-id can be argued to be related to the HW, but the
pinmux
> > > value is a hack that really has no place in device tree.
> >
> > Are you sure you have this right? The pinmux is set by the hardware,
> > since it is the board schematic which determines which SOC pins are
> > connected to the I2C bus, for example.
> >
> > There are only a few possible combinations for each port, so I believe
> > it makes sense to represent these by a number, at least until we find
> > out what Linux will do.
>
> For some peripherals, the number of options is low.
>
> For others, there are quite a few combinations.
>
> Either way, there is no "select pinmux option N" for anything; those
> "option N" values are something purely internal to the U-Boot driver,
> and don't even come from tables in the Tegra documentation.
>




> Either way as I've explained before, we can't add a temporary DT binding,
> then put a proper one in place later, since that will make old .dts files
> incompatible with new bootloaders or kernels.

Well the fts is in U-Boot so when we change the bindings in U-Boot we
change the code. I don't see the problem.

>
> > But if not, what do you propose we do instead?
>
> Given there's still a lot of flux with DT, I'd suggest adding all the
> drivers to U-Boot without any DT support at all. That should avoid all
> the contentious issues. DT support can be added later. Preferably, adding
> DT support for a given driver would happen at roughly the same time for
> both U-Boot and the Linux kernel, and get review from DT experts from
> both development teams. We may have to defer some aspects of DT support
> quite some time, since areas such as clocks and pinmux may need quite
> a bit of discussion to get right.

I understand the desire to wait, but this seems less than ideal to me. Why
not just make some changes when the kernel makes up its mind?

Look, the fdt is just an agreement between the controller and the
user/driver on the bindings to use. I think we are over-thinking this...

Regards,
Simon

>
> --
> nvpublic
>