Hi Stephen, On Wed, Oct 31, 2012 at 8:41 AM, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 10/31/2012 12:00 AM, Heiko Schocher wrote: >> Hello Stephen, >> >> On 30.10.2012 23:32, Stephen Warren wrote: >>> On 10/30/2012 11:28 AM, Simon Glass wrote: >>>> (just for illustration, please don't merge) >>>> >>>> This enables CONFIG_SYS_I2C on Tegra, updating existing boards and >>>> the Tegra >>>> i2c driver to support this. >>> >>>> diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c >>> >>>> +#ifdef CONFIG_TEGRA_I2C >>>> +extern struct i2c_adapter tegra_i2c_adap[]; >>>> +#endif >>> >>> I'm not sure why that's needed if the config files have to put the >>> adpater list into a #define: >>> >>>> diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h >>> >>>> +#define CONFIG_SYS_I2C >>>> +#define CONFIG_SYS_I2C_ADAPTERS {&tegra_i2c_adap[0]} >>>> +#define CONFIG_SYS_NUM_I2C_ADAPTERS TEGRA_I2C_NUM_CONTROLLERS >>> >>> But, why is CONFIG_SYS_I2C_ADAPTERS needed; can't the adapter init >>> functions (which presumably would be called from board code or as a >>> result of DT parsing) dynamically register themselves? >> >> This would not work, if we are running for example from flash on >> powerpc before relocation. There some boards need to read RAM >> infos from an SPD Eeprom through i2c ... so we must have very early >> i2c bus ready and usable ... >> >> It maybe a good plus to add i2c busses/adapters dynamically after >> relocation is done and we have enough RAM ... I tried such an >> approach here: >> >> http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=ccb680c8cf9002232bc459e4003e3b47db5e1bf4 >> >> but this is an old state (only rebased a long time), >> but it is maybe a good base for doing such an feature >> if it is needed ... > > I mainly ask because Simon is pushing to have Tegra's U-Boot completely > driven by device tree. If we need to hard-code the list of enabled I2C > adapters in the U-Boot config file, and don't also support dynamically > added I2C drivers, then that will be incompatible with device tree.
Mostly, although with the serial console (which had a similar problem) we just decoded the information onto the stack as needed. It was inefficient, but worked fine for a small number of operations. We might be able to do better with pre-relocation malloc() soon. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot