On Fri, 2013-11-29 at 17:32 +0800, Kuo-Jung Su wrote:
Unfortunately I still cannot agree with you. In my opinion I2C driver has nothing to do with current situation.
Yes, that's why I said the root cause is U-Boot's I2C model. The address should never be rebuilt/reformated inside the I2C driver. The better solution is to update the i2c_read/i2c_write to:
int i2c_read(struct i2c_adapter *adap, u8 dev, uint *addr, int alen, uchar *buf, int len)
or
int i2c_read(struct i2c_adapter *adap, u8 dev, uchar *buf, int len)
i.e., drop the use of uint 'addr'
Well, even in current state of I2C core and some particular drivers (like DW I2C) no reformat of address happens as far as I can tell.
But I cannot tell about each and every I2C driver in U-boot.
Still if you'd like to modify "U-Boot's I2C model" it is up to you to start this discussion/work if you haven't start it yet (sorry I don't read entire U-boot mailing list daily).
But then it's good to modify all drivers as well so nobody gets dead/not-built I2C drivers at some point, right?
It's purely how manufacturers of EEPROM use I2C. For example I we use "PCF8594C-2" EEPROM. Here's a datasheet - http://www.nxp.com/documents/data_sheet/PCF8594C_2.pdf
Its capacity is 512 bytes. And as you may see from "Fig 3. Device addressing." Each IC houses 2 virtual EEPROMs (each housing 256 bytes of data).
Yes, it looks like a special case which use BIT0 of device address for page selection. Which means we can't directly pass the device address to i2c_read/i2c_write. But it's still o.k to directly the 'offset' as what we did before.
Frankly I don't understand how passing entire "offset" will work in this particular corner-case. From my explanation you see that we have to mimic 8-bit address of target byte in EEPROM. And even if our I2C controller may use 10 bits for addressing it is something that we don't want use here - we need 8-bit as we do now.
Regards, Alexey