On Wed, Aug 03, 2016 at 02:13:17PM +0200, Lars-Peter Clausen wrote: > On 08/03/2016 06:57 AM, Alison Schofield wrote: > > 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? > > > I wouldn't worry about this too much. If the part is not SMBUS compliant > there is no need to try to access it only with SMBUS methods. A system > designer will most likely not connect the part to a SMBUS-only controller. > > What's actually quite important though at a software level is that you do > your write+read in a single I2C transaction and not split it over multiple > calls. Otherwise a device on the same I2C bus could be accessed in between > and that would really break things. > > If you want to address Jonathan's comments about backwards compatibility, > instead of returning with an error simply disable buffer mode if the host > controller only has SMBUS capabilities. > Thank Lars. I need to fix the existing direct mode reads first. That is the part that could break existing userspace. I like what you say about a system designer not connecting the part to a SMBUS-only controller, but I'm guessing this fix is going to break the user who got lucky with SMBUS-only. I'll work up a patch for fixing the existing reads (with i2c cmds) and get it out for comments. 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
