On Friday 12 December 2008, Jean Delvare wrote: > > So, should this automatically discard using SMBUS api for my case, or am > > I missing something else? (like a SMBUS 16-bit expansion or so) > > You are correct, SMBus messaging implies an 8-bit command field (which > is most frequently used for register addressing.) There are no 16-bit > command variants. How about the "proc call" ... 16 bits to the slave, 16 bits back? That would be like a "read 16 bit register with 16 bit address". ISTR we had that a routine supporting that at one point (and the infrastructure for it is still there, emulation and all) but it was removed because it was still seeking its first use. > For writes, we can cheat because there is no > direction change between the address and the data, Cheat how? > but for reads > there's simply nothing we can do to work around this limitation. So, > unless your device is write-only, you indeed can't use the SMBus-level > API for 16-bit register addresses and you have to stick to the > I2C-level API. If addresses and data are both 16 bits, I only see how to do reads, not writes, within the scope of the SMBus calls. Of course, SMBus also supports byte and (small-)counted-array data too. - Dave > -- > Jean Delvare > > -- 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
