Hi Jean, Jean Delvare wrote: >Hi Randy and all, > >Sorry for the delay. > >[Eugene Surovegin] > > >>I wonder, why you chose to use those 1-byte SMBus transfers instead >>of i2c transfer. >> >> > >[Randy Vinson] > > >>I was simply following the guidelines in >>Documentation/i2c/writing-clients as noted in the driver header. This >>note was in the driver I used as my base, so I just followed along. >> >> > >The document file says: > >"If you can choose between plain i2c communication and SMBus level >communication, please use the last. All adapters understand SMBus level >commands, but only some of them understand plain i2c!" > >The "if you can choose" is important. It doesn't suggest that you should >use a less efficient way, but that you use the SMBus API when the I2C >transfer you want to use happens to exist in the SMBus API. > >Even when sticking to SMBus commands, it is quite frequent that there >are different ways to retrieve the same information, of varying >availability and speed. One good example of this are EEPROMs. EEPROMs >are I2C devices which can be accessed using SMBus commands. You can read >bytes one by one (SMBus Read Byte Data command), or continuously as >different reads (first one SMBus Write Byte, then many SMBus Read Byte), >or continuously as a single read (I2C Block Read, supported by some >SMBus controllers). If you look at the eeprom.c drivers, you'll see that >the second and the third method are both implemented. The advantage is >that: > I interpreted the doc the same way Randy did when I did the m41t00 chip code. Also, Mark Studebaker seemed to support that interpretation in this email: http://archives.andrew.net.au/lm-sensors/msg29325.html I suppose the best thing to do is check if the adapter is a true i2c ctlr (something like: i2c_check_functionality(adapter, I2C_FUNC_I2C)) and base the cmds used on that. We can do something similar with I2C_FUNC_SMBUS_READ_I2C_BLOCK & I2C_FUNC_SMBUS_WRITE_BLOCK_DATA to check if we can use the smbus block cmds too, correct? Mark
