[U-Boot] [PATCH v2 4/4] cmd_eeprom: bug fix for i2c read/write

[Alexey Brodkin]

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