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.