On 07/30/2013 11:46 PM, Heiko Schocher wrote: ... > Hmm.. each i2c adapter has its own init function ... why the tegra > driver do not use it? And do the necessary inits in it? So we > initialize an adapater only if we use it, which is also a rule > for u-boot ... > > I have no hw, but it should be possible to add to process_nodes() > a parameter "controller_number" and call > process_nodes(controller_number, ...) from the i2c drivers init > function ...
There are two steps to initializing I2C on a Tegra system: 1) Parsing the DT to determine which/how-many I2C adapters exist in the SoC. This will yield information such as the register address of the I2C adapters, which clock/reset signal they rely on, perhaps the max bus clock rate, etc. This is a single global operation that needs to happen one single time before anything else. This stage initializes the i2c_controllers[] array, since that's what stores all the data parsed from DT. 2) Actually initializing or using the I2C HW. That could certainly be part of the per-I2C-controller init() function you mention. Now, I think the big disconnect here is that historically, the U-Boot binary has hard-coded all the details that step (1) above parses out of DT, so that step (1) did not need to exist. However, Simon has been pushing Tegra towards not hard-coding any of this information, but instead having a single binary that can work on arbitrary Tegra boards and even across different Tegra SoCs which have a different number of I2C controllers at different register addresses. This is quite fundamentally different to how U-Boot has worked in the past, and evidently has some problems fitting into the typical U-Boot initialization sequence. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
