k...@koi8.net wrote:
> That looks similar. But why do you want to remove i2c_set_bus_num()? I think
> it would be less work to keep it.
Perhaps, but it would be even better to get rid of it. IMHO, it's a kludge. It
was a hack added to allow existing I2C routines to function while adding minimal
support for multiple buses on those platforms that needed it.
> This way you can leave 90% or so of
> existing I2C code unchanged by setting bus number to 0 at init.
I only intend on exporting the multiple-bus versions of the I2C function if
CONFIG_I2C_MULTI_BUS is defined.
> My idea is to have global bus number variable in a single place and a single
> i2c_set_bus_num() that can be excluded for most boards with a single bus
> with #ifdef...
We already have something like that. A global variable is inconvenient because
every time you want to access the bus, you need to do something like this:
bus = i2c_get_bus_num();
i2c_set_bus_num(x);
i2c_write(...)
i2c_set_bus_num(bus);
We need to save/restore the current bus number, because the I2C command-line has
the concept of a
> Then, we could use some kind of array of I2C structures each containing
> pointers to appropriate i2c-{read,write,probe,init}() functions with generic
> i2c functions just calling those pointers using bus number as index into
> that array.
Sounds complicated.
> That would allow for unlimited number of different adapters for any board.
Ah, now this is something else entirely. I don't think U-boot supports this at
all. I think you're being too ambitious. It's a noble idea, and I think U-boot
should support it, but I think we need to simplify the support for multiple
buses first.
> Initial code for initializing such an array would have to go into each and
> every $(BOARD).c board specific file.
Ugh.
--
Timur Tabi
Linux kernel developer at Freescale
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
