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. -- KR Michael -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
