Hello ksi, k...@koi8.net wrote: > On Wed, 18 Feb 2009, Wolfgang Denk wrote: > >> Dear k...@koi8.net, >> >> In message <pine.lnx.4.64ksi.0902171456520.30...@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 -- 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
