From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Wed, 18 Feb 2009 08:47:49 +0100 Subject: [U-Boot] [PATCH] 7/12 Multiadapter/multibus I2C, drivers part 4 In-Reply-To: References: <499548C2.7060305@denx.de> <49967FAC.6090905@denx.de> <20090216221151.08966832E893@gemini.denx.de> <20090217224940.02BC6832E893@gemini.denx.de> <20090218001322.4A43C832E893@gemini.denx.de> Message-ID: <499BBD25.4070907@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello ksi, ksi at koi8.net wrote: > On Wed, 18 Feb 2009, Wolfgang Denk wrote: > >> Dear ksi at koi8.net, >> >> In message 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