From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 30 Oct 2012 06:57:08 +0100 Subject: [U-Boot] [PATCH 0/3] Bring in new I2C framework In-Reply-To: <508EA1FC.5090503@wwwdotorg.org> References: <1350927621-12481-1-git-send-email-hs@denx.de> <508A2420.2000207@denx.de> <508AB52C.80300@wwwdotorg.org> <508E50A7.3020407@denx.de> <508EA1FC.5090503@wwwdotorg.org> Message-ID: <508F6C34.6000605@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 Stephen, On 29.10.2012 16:34, Stephen Warren wrote: > On 10/29/2012 03:47 AM, Heiko Schocher wrote: >> Hello Stephen, >> >> On 26.10.2012 18:07, Stephen Warren wrote: >>> On 10/25/2012 11:48 PM, Heiko Schocher wrote: >>>> Hello Simon, >>>> >>>> On 25.10.2012 23:37, Simon Glass wrote: >>>>> On Mon, Oct 22, 2012 at 10:40 AM, Heiko Schocher wrote: [...] >>> That rather relies on their being a concept of a "current" I2C adapter. >>> It seems a little limiting to require that. What if the "current" >>> adapter is the user-selected adapter for commands to operate on, but >>> e.g. some power-management driver wants to use I2C to communicate with a >>> PMIC during the internals of some other command. Sure, you could save >>> and later restore the I2C core's idea of "current" adapter, but it'd >>> surely be cleaner to just pass around the I2C adapter ID or struct >>> pointer everywhere to avoid the need for save/restore. >> >> Yes, you are right, but just the same problem with current code! >> You mixed here two things! > > I think you're reading more into what I was saying than what I actually > said. Sorry, maybe I misunderstood you ... > If there are e.g. 4 I2C controllers in an SoC, the driver needs to know > which one is in use. Passing that information directly to the driver > functions is much simple than requiring the SoC I2C driver to go grovel > in some I2C core global variables to find out the same information. Ah, do you mean we should change the i2c adapter struct from: struct i2c_adapter { void (*init)(int speed, int slaveaddr); int (*probe)(uint8_t chip); int (*read)(uint8_t chip, uint addr, int alen, uint8_t *buffer, int len); int (*write)(uint8_t chip, uint addr, int alen, uint8_t *buffer, int len); uint (*set_bus_speed)(uint speed); [...] to struct i2c_adapter { void (*init)(struct i2c_adapter *adap, int speed, int slaveaddr); int (*probe)(struct i2c_adapter *adap, uint8_t chip); int (*read)(struct i2c_adapter *adap, uint8_t chip, uint addr, int alen, uint8_t *buffer, int len); int (*write)(struct i2c_adapter *adap, uint8_t chip, uint addr, int alen, uint8_t *buffer, int len); uint (*set_bus_speed)(struct i2c_adapter *adap, uint speed); [...] ? We can do this. Simon suggested this too ... @Simon: Is this Ok with you? Nevertheless, we need a "cur_i2c_bus" pointer, as the i2c core, needs to know the current i2c bus for detecting if the bus, which whould be accessed is the current or not and a switching to another bus is needed. > This is all unrelated to I2C bus muxes; they shouldn't be implemented as > part of an SoC I2C driver anyway, so the driver shouldn't know about bus > muxes before or after this patch - the I2C core should manage that. Exactly! And that do the new i2c framework in i2c_core.c! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany