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