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

[Heiko Schocher]

Hello ksi,

ksi at koi8.net wrote:
> 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:
[...]
>>> 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