Jean Delvare said the following:
> Hi Yang, Wolfram,
> On Fri, 05 Mar 2010 15:53:44 +0800, Yang Shi wrote:
>> Wolfram Sang 写道:
>> >>> Is the use of 'eeprom' instead of 'at24' intentional?
>> >> Unfortunately, at24 driver can't work on this board, I must use legacy
>> >> eeprom.
>> > Well, you are of course free to choose here :)
>> > I'd just be interested if there is a software limitation which prevents
>> > you from
>> > using AT24. Because, it _should_ work with all kind of eeproms the legacy
>> > driver
>> > deals with. Otherwise it is probably a bug which needs to be fixed.
>> Thanks to point out this. Let me take a look at this.
> One limitation of the at24 driver is that it needs the underlying
> controller to support either raw I2C access or at least I2C block
> transactions. Konstantin Lazarev complained about that one month ago
> I am currently working on improving the at24 driver so that it falls
> back to byte transactions when block transactions are not available. I
> might also add word transaction support (as the eeprom driver has) as
> it is often the best performance/compatibility trade-off. I'll post the
> patch when I'm done.
> I'm not yet sure what will happen to the legacy eeprom driver in the
> long run, but I would prefer new designs to not rely on it.
If I don't get all wrong, my 2 Cents:
i2c-octeon will/should be based on raw i2c from kernel version .34 on.
(my patch :-) ) So it should support all transfer modes that i2c can.
Currently it is limited to 8 bytes per transaction.
If I misunderstood something, please ignore the noise.