Hello ksi,
ksi@koi8.net wrote:
On Wed, 18 Feb 2009, Wolfgang Denk wrote:
Dear ksi@koi8.net,
In message Pine.LNX.4.64ksi.0902171456520.30777@home-gw.koi8.net you wrote:
[...]
OK, this is not about using multiple I2C busses before relocation and using them right now for any of existing boards (some of which are actually dead or vaporware.)
...
We agree that there are cases where multiple busses are needed. But do we need such complexity before relocation?
It is not before relocation. I don't see a reason to do this before relocation either. But if we want to have such a possibility after relocation we also need a mechanism to do this.
But, if this current pointer is writeable, it is also usable before relocation!
And it is not all that complex, I can't understand why you think it is.
We actually mix things:
- complex: There we (Wolfgang and I) talk about your implentation of the bitbang driver
not about your i2c-core ...
As for now we have a set of regular i2c functions (i2c_init/i2c_read/etc.) in each and every i2c driver. Those functions are exported so when we pick up a driver (with e.g. CONFIG_HARD_I2C that metastasize through the entire U-Boot source choosing different drivers for different platforms) those functions get called where i2c_read() etc. are used.
I make all those functions static so they are not exported and add a simple exported structure with pointers to those functions. Then there is one wrapper, i2c_core.c that holds global bus number and exports that usual set of i2c_read() and friends. Those functions in turn just play a dispatcher role calling appropriate functions from an array of those driver structures using current bus number as an index into that array. There is nothing more complex than that.
Perfectly.
The i2c_set_bus_number() is a bit more complex than just changing that global variable to accomodate multiplexed busses but not rocket science either -- if the current bus is multiplexed, it switches off all the muxes in the path starting with the farthest one (if it is multihop, but I doubt we'll see such a beast so it will be just one chip) and turn on the muxes for the new bus (if it is multiplexed) starting with the closest one. The companion i2c_get_bus_num() just returns that global variable.
Ok.
What is that complex with such a design?
Nothing. And there is not even more complexity, when we add a current pointer, or? We just can use this current pointer, to make driver code more simpler by using this current pointer and hwadapnr ...
See: http://lists.denx.de/pipermail/u-boot/2009-February/047487.html
bye Heiko