[U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren <swarren@wwwdotorg.org>]

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.