linux/drivers/i2c, branch v2.6.27.54

i2c-tiny-usb: Fix on big-endian systems

2010-05-26T21:27:09Z

commit 1c010ff8912cbc08d80e865aab9c32b6b00c527d upstream. The functionality bit vector is always returned as a little-endian 32-bit number by the device, so it must be byte-swapped to the host endianness. On the other hand, the delay value is handled by the USB stack, so no byte swapping is needed on our side. This fixes bug #15105: http://bugzilla.kernel.org/show_bug.cgi?id=15105 Reported-by: Jens Richter Signed-off-by: Jean Delvare Tested-by: Jens Richter Cc: Till Harbaum Signed-off-by: Greg Kroah-Hartman

i2c-i801: Don't use the block buffer for I2C block writes

2010-05-26T21:27:08Z

commit c074c39d62306efa5ba7c69c1a1531bc7333d252 upstream. Experience has shown that the block buffer can only be used for SMBus (not I2C) block transactions, even though the datasheet doesn't mention this limitation. Reported-by: Felix Rubinstein Signed-off-by: Jean Delvare Cc: Oleg Ryjkov Signed-off-by: Greg Kroah-Hartman

i2c: Fix probing of FSC hardware monitoring chips

2010-05-26T21:27:08Z

commit b1d4b390ea4bb480e65974ce522a04022608a8df upstream. Some FSC hardware monitoring chips (Syleus at least) doesn't like quick writes we typically use to probe for I2C chips. Use a regular byte read instead for the address they live at (0x73). These are the only known chips living at this address on PC systems. For clarity, this fix should not be needed for kernels 2.6.30 and later, as we started instantiating the hwmon devices explicitly based on DMI data. Still, this fix is valuable in the following two cases: * Support for recent FSC chips on older kernels. The DMI-based device instantiation is more difficult to backport than the device support itself. * Case where the DMI-based device instantiation fails, whatever the reason. We fall back to probing in that case, so it should work. This fixes kernel bug #15634: https://bugzilla.kernel.org/show_bug.cgi?id=15634 Signed-off-by: Jean Delvare Acked-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

i2c: Do not use device name after device_unregister

2010-04-01T22:52:21Z

In Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c556752109794a5ff199b80a1673336b4df8433a dev_dbg outputs dev_name, which is released with device_unregister. This bug resulted in output like this: i2c Xy2�0: adapter [SMBus I801 adapter at 1880] unregistered The right output would be: i2c i2c-0: adapter [SMBus I801 adapter at 1880] unregistered Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

i2c/tsl2550: Fix lux value in extended mode

2010-01-06T23:17:12Z

commit 5f5bfb09d81c9a1d26238ae6668e584c14ae3daf upstream. According to the TAOS Application Note 'Controlling a Backlight with the TSL2550 Ambient Light Sensor' (page 14), the actual lux value in extended mode should be obtained multiplying the calculated lux value by 5. Signed-off-by: Michele Jr De Candia Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

i2c/tsl2550: Fix lux value in dark environment

2009-08-16T21:26:23Z

commit 96f699ad09c8b3c55cd229506a9add0047838e3e upstream. I've tested TSL2550 driver and I've found a bug: when light is off, returned value from tsl2550_calculate_lux function is -1 when it should be 0 (sensor correctly read that light was off). I think the bug is that a zero c0 value (approximated value of ch0) is misinterpreted as an error. Signed-off-by: Michele Jr De Candia Acked-by: Rodolfo Giometti Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

i2c-algo-pca: Let PCA9564 recover from unacked data byte (state 0x30)

2009-05-20T05:20:08Z

commit 2196d1cf4afab93fb64c2e5b417096e49b661612 upstream Currently, the i2c-algo-pca driver does nothing if the chip enters state 0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been received). Thus, the i2c bus connected to the controller gets stuck afterwards. I have seen this kind of error on a custom board in certain load situations most probably caused by interference or noise. A possible reaction is to let the controller generate a STOP condition. This is documented in the PCA9564 data sheet (2006-09-01) and the same is done for other NACK states as well. Further, state 0x38 isn't handled completely, either. Try to do another START in this case like the data sheet says. As this couldn't be tested, I've added a comment to try to reset the chip if the START doesn't help as suggested by Wolfram Sang. Signed-off-by: Enrik Berkhan Reviewed-by: Wolfram Sang Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

i2c-algo-bit: Fix timeout test

2009-05-20T05:20:08Z

commit 0cdba07bb23cdd3e0d64357ec3d983e6b75e541f upstream When fetching DDC using i2c algo bit, we were often seeing timeouts before getting valid EDID on a retry. The VESA spec states 2ms is the DDC timeout, so when this translates into 1 jiffie and we are close to the end of the time period, it could return with a timeout less than 2ms. Change this code to use time_after instead of time_after_eq. Signed-off-by: Dave Airlie Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman

ARM: Add i2c_board_info for RiscPC PCF8583

2009-03-17T00:53:03Z

commit 531660ef5604c75de6fdead9da1304051af17c09 upstream Add the necessary i2c_board_info structure to fix the lack of PCF8583 RTC on RiscPC. Signed-off-by: Russell King Signed-off-by: Jean Delvare Cc: Alessandro Zummo Signed-off-by: Greg Kroah-Hartman

i2c: Timeouts reach -1

2009-03-17T00:53:03Z

commit a746b578d8406b2db0e9f0d040061bc1f78433cf upstream With a postfix decrement these timeouts reach -1 rather than 0, but after the loop it is tested whether they have become 0. As pointed out by Jean Delvare, the condition we are waiting for should also be tested before the timeout. With the current order, you could exit with a timeout error while the job is actually done. Signed-off-by: Roel Kluin Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman