On Mon, Mar 09, 2015 at 05:02:31PM +0000, Jonathan Cameron wrote: > On 09/03/15 16:45, Wolfram Sang wrote: > > On Mon, Mar 09, 2015 at 03:41:30PM +0000, Jonathan Cameron wrote: > >> On 09/03/15 15:35, Jonathan Cameron wrote: > >>> On 25/02/15 15:55, Vianney le Clément de Saint-Marcq wrote: > >>>> Add device attributes for getting/setting emissivity, IIR, and FIR > >>>> coefficients, and getting the gain (which should not be modified in > >>>> order to keep factory calibration). > >>>> > >>>> The attributes provide raw values whose meaning is described in the > >>>> datasheet [1]. > >>>> > >>>> Writing to EEPROM requires an explicit erase by writing zero. In > >>>> addition, it takes 20ms for the erase/write to complete. During this > >>>> time no EEPROM register should be accessed. Therefore, two msleep()s > >>>> are added to the write function and a mutex protects against concurrent > >>>> access. > >>>> > >>>> Since it is not expected to be updated frequently, the configuration > >>>> register is read before modifying it rather than caching it. > >>>> > >>>> [1] http://melexis.com/Assets/IR-sensor-thermometer-MLX90614-Datasheet-5152.aspx > >>>> > >>>> Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@xxxxxxxxxxxxx> > >>>> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@xxxxxxx> > >>> Wolfram, bit of odd i2c usage inline I'd like you to take quick look at. > > > > What do you mean? The direct calls to i2c_smbus_xfer? Was there any > > reason given to use it directly? > Apparently the returned PEC is present but wrong. However it requires > a correct PEC to be transmitted to it. Genious Ouch. Well, in such a case I think it is okay to call i2c_smbus_transfer directly, especially since it is described well in the comment. lm90 does this, too. But there, it is the writes that are broken. I don't feel to add quirk flags for all possible permutations of this problem.
Attachment:
signature.asc
Description: Digital signature
