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: > > > > > [On the other hand I still wonder why I have never seen any such > > > board appear to me in real life yet. None of the 500+ boards > > > supported in U-Boot uses any such configuration.] > > > > Eh, for those 500+ (actually 472 judging on the number of files in > > include/configs) boards there are at least twice that many that were never > > There are some boards that share one config file...
Yes, I know. > > 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. And it is not all that complex, I can't understand why you think it is. 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. 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. And that's all to it. What is that complex with such a design? --- ****************************************************************** * k...@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ****************************************************************** _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
