From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Tue, 30 Oct 2012 22:20:01 -0700 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: <20121031052001.GJ15024@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Oct 30, 2012 at 10:22:54AM -0700, 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? Funny enough I don't see a UDM-i2c.txt file, so I guess the community gets to think about that one :) -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: