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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
