[U-Boot] [PATCH 2/2] WIP: tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

On 11/07/2012 11:47 PM, Heiko Schocher wrote:
> On 01.11.2012 18:03, Stephen Warren wrote:
...
>> I'd suggest having a CONFIG_SYS_I2C_DRIVERS variable at most, and each
>> driver registers an arbitrary number of adapters and/or buses during its
>> initialization.
> 
> Why should an i2c driver register buses? That is board specific.

I don't entirely agree here. Certainly the information is
board-specific, but I don't believe that precludes bus registration
occurring from the I2C adapter drivers themselves, based on information
passed from a board file or device tree.

If a particular adapter is instantiated by the board, then there is
clearly an I2C bus attached to that adapter. Hence, it's quite
reasonable for the adapter itself to register the bus directly attached
to it.

Following on from there, if there's an I2C bus mux attached to some I2C
bus, then there are clearly I2C buses downstream from the bus mux, and
the bus mux driver knows exactly how many there are, and can register
those buses.

This can continue through a whole tree of I2C adapters/muxes/buses.

The above model fits into device tree very well; in that case, you only
find out about the existence of downstream muxes etc. once you've
initialized the I2C adapter for the parent bus.

Equally, I think this model can work very well for manually coded board
files; the board file can directly instantiate all top-level I2C
adapters, and pass information to the I2C driver for those adapters
indicating which I2C devices are attached to the buses. Then, if one of
those devices happens to be an I2C bus mux, it can instantiate further
I2C buses, which in turn instantiate more devices based on the
parameters passed to the I2C bus mux driver.

>> We could probably even get away without CONFIG_SYS_I2C_DRIVERS at all;
>> just have each driver define a structure that gets put into a special
>> linker section, so that the I2C core can iterate over all linked drivers
>> at boot time and call their initialization functions.
>>
>> Even if we don't get rid of CONFIG_SYS_I2C_ADAPTERS, I really think we
>> should get rid of CONFIG_SYS_I2C_BUSSES and do that dynamically.
> 
> How do we this, for example on some powerpc boards, which boot from
> NOR flash and read a SPD EEprom data for RAM initialization (Note: we
> have here not a lot of stack, nor RAM)? Maybe we should wait with this
> hole patchserie until DM is ready? (And maybe rework it completly?)

I'd expect SPD initialization to be a special case in a U-Boot SPL;
isn't that its purpose?