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

[Heiko Schocher]

Hello Stephen,

On 08.11.2012 18:05, Stephen Warren wrote:
> 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.

But some i2c drivers have more than one instance... would you for all
boards register all possible instances of a driver? ... A lot of boards
do not use the multibus feature, and so they use only one i2c driver ...
on this boards we would register maybe a lot of buses for nothing ...

> 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.

Here again, why register all possible buses? We are just a bootloader ...

> 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.

Yep, possible ... but another approach ...

>>> 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?

We have boards which are booting from NOR flash and reading a SPD EEprom
without using SPL ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany