[U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4

[ksi at koi8.net]

On Wed, 18 Feb 2009, Wolfgang Denk wrote:

> Dear ksi at koi8.net,
> 
> In message <Pine.LNX.4.64ksi.0902171456520.30777 at 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?

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************