Hi guys,Thanks for you guys kind advice. I think I find the cause. I coded a wrong eeprom type, "at24" can't work here, it should be "24c64". It works with AT24 eeprom driver, but I'm not sure if this is the right type.
So, a possible correct to the patch is that:
+{
+ I2C_BOARD_INFO("24c64",·0x50),
+},
Regards,
Yang
Michael Lawnick 写道:
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 already. 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.
