From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Wed, 31 Oct 2012 06:02:03 +0100 Subject: [U-Boot] [PATCH 0/3] Bring in new I2C framework In-Reply-To: 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> <508F6C34.6000605@denx.de> <50900570.5080305@wwwdotorg.org> Message-ID: <5090B0CB.1030209@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 Simon, On 30.10.2012 18:22, Simon Glass wrote: > Hi, > > On Tue, Oct 30, 2012 at 9:50 AM, Stephen Warren wrote: >> On 10/29/2012 11:57 PM, Heiko Schocher wrote: >>> Hello Stephen, >>> >>> On 29.10.2012 16:34, Stephen Warren wrote: >> ... >>>> 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 ... >> >> Yes, exactly. (the functions will need some way to get information out >> of the struct i2c_adapter; I assume there's some kind of driver_private >> field in there too). > > Yes. > > I will post a few patches to move Tegra over to the new framework as > it is, so that people can see the impact. Given that every driver has > to change, it would be my preference to set the i2c API once. But I > suppose within a short while everything will move to the device model, > so perhaps the job of this series is just to move things in the right > direction? Yes, but not only, I think the i2c framework needs an update. bye, heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany