linux/drivers/i2c, branch v3.18

i2c: cadence: Set the hardware time-out register to maximum value

2014-12-04T18:25:41Z

Cadence I2C controller has bug wherein it generates invalid read transactions after timeout in master receiver mode. This driver does not use the HW timeout and this interrupt is disabled but the feature itself cannot be disabled. Hence, this patch writes the maximum value (0xFF) to this register. This is one of the workarounds to this bug and it will not avoid the issue completely but reduces the chances of error. Signed-off-by: Vishnu Motghare Signed-off-by: Harini Katakam Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: davinci: generate STP always when NACK is received

2014-12-04T18:25:31Z

According to I2C specification the NACK should be handled as follows: "When SDA remains HIGH during this ninth clock pulse, this is defined as the Not Acknowledge signal. The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer." [I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf] Currently the Davinci i2c driver interrupts the transfer on receipt of a NACK but fails to send a STOP in some situations and so makes the bus stuck until next I2C IP reset (idle/enable). For example, the issue will happen during SMBus read transfer which consists from two i2c messages write command/address and read data: S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P <--- write -----------------------> <--- read ---------------------> The I2C client device will send NACK if it can't recognize "Command Code" and it's expected from I2C master to generate STP in this case. But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will not be generated. Hence, fix it by generating Stop condition (STP) always when NACK is received. This patch fixes Davinci I2C in the same way it was done for OMAP I2C commit cda2109a26eb ("i2c: omap: query STP always when NACK is received"). Reviewed-by: Uwe Kleine-König Reported-by: Hein Tibosch Signed-off-by: Grygorii Strashko Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: omap: fix i207 errata handling

2014-11-22T21:07:40Z

commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by errata. According to errata ISR must filter out spurious RDR before data read not after. ISR must read RXSTAT to get number of bytes available to read. Because RDR could be set while there could no data in the receive FIFO. Restored pre 6d9939f6514 way of handling errata. Found by code review. Real impact haven't seen. Tested on Beagleboard XM C. Signed-off-by: Alexander Kochetkov Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY Tested-by: Felipe Balbi Reviewed-by: Felipe Balbi Signed-off-by: Wolfram Sang

i2c: designware: prevent early stop on TX FIFO empty

2014-11-21T07:06:32Z

If the Designware core is configured with IC_EMPTYFIFO_HOLD_MASTER_EN set to zero, allowing the TX FIFO to become empty causes a STOP condition to be generated on the I2C bus. If the transmit FIFO threshold is set too high, an erroneous STOP condition can be generated on long transfers - particularly where the interrupt latency is extended. Signed-off-by: Andrew Jackson Signed-off-by: Liviu Dudau Tested-by: Mika Westerberg Signed-off-by: Wolfram Sang

i2c: omap: fix NACK and Arbitration Lost irq handling

2014-11-21T07:06:31Z

commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts) changed the interrupt handler to complete transfers without clearing XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be fired again. As a result, ISR keep processing transfer after it was already complete (from the driver code point of view). A didn't see real impacts of the 1d7afc9, but it is really bad idea to have ISR running on user data after transfer was complete. It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32). According to specs (if I understood correctly), in case of NACK and AL driver must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and NACK, AL, ARDY, and XDR (Master Transmitter Mode). All that is done down the code under the if condition: if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ... The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so no interrupts is fired after ISR informs the rest of driver what transfer complete. Note: instead of removing break under NACK case, we could just replace 'break' with 'continue' and allow NACK transfer to finish using ARDY event. I found that NACK and ARDY bits usually set together. That case confirm TI wiki: http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK In order if someone interested in the event traces for NACK and AL cases, I sent them to mailing list. Tested on Beagleboard XM C. Signed-off-by: Alexander Kochetkov Fixes: 1d7afc9 i2c: omap: ack IRQ in parts Cc: # v3.7+ Acked-by: Felipe Balbi Tested-by: Aaro Koskinen Signed-off-by: Wolfram Sang

i2c: core: Dispose OF IRQ mapping at client removal time

2014-11-07T18:03:18Z

Clients instantiated from OF get an IRQ mapping created at device registration time. Dispose the mapping when the client is removed. Signed-off-by: Laurent Pinchart Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: at91: don't account as iowait

2014-11-07T17:56:31Z

iowait is for blkio [1]. I2C shouldn't use it. [1] https://lkml.org/lkml/2014/11/3/317 Signed-off-by: Wolfram Sang Acked-by: Ludovic Desroches Cc: stable@kernel.org

i2c: remove FSF address

2014-11-07T17:35:33Z

We have a central copy of the GPL for that. Some addresses were already outdated. Signed-off-by: Wolfram Sang

Merge branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2014-10-19T19:50:44Z

Pull i2c updates from Wolfram Sang: "Highlights from the I2C subsystem for 3.18: - new drivers for Axxia AM55xx, and Hisilicon hix5hd2 SoC. - designware driver gained AMD support, exynos gained exynos7 support The rest is usual driver stuff. Hopefully no lowlights this time" * 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: i801: Add Device IDs for Intel Sunrise Point PCH i2c: hix5hd2: add i2c controller driver i2c-imx: Disable the clock on probe failure i2c: designware: Add support for AMD I2C controller i2c: designware: Rework probe() to get clock a bit later i2c: designware: Default to fast mode in case of ACPI i2c: axxia: Add I2C driver for AXM55xx i2c: exynos: add support for HSI2C module on Exynos7 i2c: mxs: detect No Slave Ack on SELECT in PIO mode i2c: cros_ec: Remove EC_I2C_FLAG_10BIT i2c: cros-ec-tunnel: Add of match table i2c: rcar: remove sign-compare flaw i2c: ismt: Use minimum descriptor size i2c: imx: Add arbitration lost check i2c: rk3x: Remove unlikely() annotations i2c: rcar: check for no IRQ in rcar_i2c_irq() i2c: rcar: make rcar_i2c_prepare_msg() *void* i2c: rcar: simplify check for last message i2c: designware: add support of platform data to set I2C mode i2c: designware: add support of I2C standard mode

i2c: i801: Add Device IDs for Intel Sunrise Point PCH

2014-10-16T07:16:22Z

This patch adds the I2C/SMBus Device IDs for the Intel Sunrise Point PCH. Signed-off-by: James Ralston Signed-off-by: Wolfram Sang