From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 28 Dec 2011 22:40:38 -0800 Subject: [U-Boot] [PATCH 2/7] tegra: fdt: Add extra I2C definitions for U-Boot In-Reply-To: References: <1324923111-340-1-git-send-email-sjg@chromium.org> <1324923111-340-3-git-send-email-sjg@chromium.org> <74CDBE0F657A3D45AFBB94109FB122FF176CC74422@HQMAIL01.nvidia.com> Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF17755DC8D4@HQMAIL01.nvidia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Simon Glass wrote at Monday, December 26, 2011 10:15 PM: > On Mon, Dec 26, 2011 at 8:35 PM, Stephen Warren 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. > 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. -- nvpublic