I'm blocked on this smbus read problem. hdc100x triggered buffer review feedback pointed out that I cannot rely on i2c_master_recv() since this driver currently only requires smbus funcs. That led me to create an alternative path using smbus byte reads like the driver was doing in direct mode. I found the reads don't work. hdc100x does not expect a stop condition after sending the first byte which is what smbus_read_byte gives you. So, when you do the second read, you are getting the first byte again. Net effect is that of the 14 bits used for the measurement, the 8 most significant bits are correct, the lower 6 are not. hdc100x only wants this: S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P I tried by testing, and by inspection, each flavor of smbus read and none match the pattern that hdc100x wants. (read_byte, read_word_data, read_word_swapped, read_block_data, read_i2c_block_data all fail) The read_byte is actually the only smbus read command the sensor accepts. Texas Instruments publishes this doc explaining its SMBus (in)compatibility. http://www.ti.com/lit/an/sloa132/sloa132.pdf I did get one lead out of it. It suggests using the write block protocol, with the READ bit set. That does look like it could work. I tried using i2c_smbus_xfer() directly, thinking maybe I could fool it, but that doesn't get me down to the low level of control I think I would need to pull this off. I see flags for i2c_msg that might be helpful...if they worked at the smbus level: I2C_M_REV_DIR_ADDR reverses r/w bit I2C_M_NOSTART strips off that beginning segment we don't want If we could use a NOSTOP flag on the read byte command then i could go back and get the next byte. I don't see such a flag. I don't see any flags, other than for PEC, on smbus. Also, saw an MDELAY flag that seemed interesting, as if I could program the delay between starting and reading the measurement, so it could all be done in one block data command. Again, not smbus. I guess these ideas are all breaking the idea of being smbus compliant anyway. Is this fixable with smbus? If not, how do you 'graciously' change a drivers requirements? Thanks, alisons -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
