From cc33e54290ed845904dac4b047934207738f0205 Mon Sep 17 00:00:00 2001 From: Bernhard Walle Date: Mon, 27 Sep 2010 12:55:16 +0200 Subject: i2c-octeon: Return -ETIMEDOUT in octeon_i2c_wait() on timeout It doesn't make sense to set result to -ETIMEDOUT but return 0 (success) afterwards. Since there's code in octeon_i2c_start() to handle the error, it should be called. Signed-off-by: Bernhard Walle Acked-by: David Daney Signed-off-by: Ben Dooks --- drivers/i2c/busses/i2c-octeon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/i2c/busses/i2c-octeon.c b/drivers/i2c/busses/i2c-octeon.c index 0e9f85d0a835..56dbe54e8811 100644 --- a/drivers/i2c/busses/i2c-octeon.c +++ b/drivers/i2c/busses/i2c-octeon.c @@ -218,7 +218,7 @@ static int octeon_i2c_wait(struct octeon_i2c *i2c) return result; } else if (result == 0) { dev_dbg(i2c->dev, "%s: timeout\n", __func__); - result = -ETIMEDOUT; + return -ETIMEDOUT; } return 0; -- cgit v1.2.3-55-g7522 From 4bba0fd8d1c6d405df666e2573e1a1f917098be0 Mon Sep 17 00:00:00 2001 From: Jon Povey Date: Fri, 17 Sep 2010 12:02:11 +0900 Subject: i2c-davinci: Fix race when setting up for TX When setting up to transmit, a race exists between the ISR and i2c_davinci_xfer_msg() trying to load the first byte and adjust counters. This is mostly visible for transmits > 1 byte long. The hardware starts sending immediately that MDR is loaded. IMR trickery doesn't work because if we start sending, finish the first byte and an XRDY event occurs before we load IMR to unmask it, we never get an interrupt, and we timeout. Move the MDR load after DXR,IMR loads to avoid this race without locking. Tested on DM355 connected to Techwell TW2836 and Wolfson WM8985 Signed-off-by: Jon Povey Signed-off-by: Ben Dooks --- drivers/i2c/busses/i2c-davinci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'drivers') diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c index 2222c87876b9..b8feac5f2ef4 100644 --- a/drivers/i2c/busses/i2c-davinci.c +++ b/drivers/i2c/busses/i2c-davinci.c @@ -357,9 +357,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) dev->terminate = 0; - /* write the data into mode register */ - davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); - /* * First byte should be set here, not after interrupt, * because transmit-data-ready interrupt can come before @@ -371,6 +368,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop) dev->buf_len--; } + /* write the data into mode register; start transmitting */ + davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, flag); + r = wait_for_completion_interruptible_timeout(&dev->cmd_complete, dev->adapter.timeout); if (r == 0) { -- cgit v1.2.3-55-g7522 From 7031307aefb6048377385dbb0af2dd43bb0190bb Mon Sep 17 00:00:00 2001 From: MyungJoo Ham Date: Thu, 30 Sep 2010 15:54:46 +0200 Subject: i2c-s3c2410: fix calculation of SDA line delay S3C2440 style I2C controller uses PCLK to calculate the SDA line delay. The driver wrongly assumed that this delay is calculated from the frequency that the controller is operating on. This patch fixes this issue. Signed-off-by: MyungJoo Ham Signed-off-by: Kyungmin Park Signed-off-by: Marek Szyprowski Signed-off-by: Ben Dooks --- drivers/i2c/busses/i2c-s3c2410.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'drivers') diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c index 72902e0bbfa7..bf831bf81587 100644 --- a/drivers/i2c/busses/i2c-s3c2410.c +++ b/drivers/i2c/busses/i2c-s3c2410.c @@ -662,8 +662,8 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c, unsigned int *got) unsigned long sda_delay; if (pdata->sda_delay) { - sda_delay = (freq / 1000) * pdata->sda_delay; - sda_delay /= 1000000; + sda_delay = clkin * pdata->sda_delay; + sda_delay = DIV_ROUND_UP(sda_delay, 1000000); sda_delay = DIV_ROUND_UP(sda_delay, 5); if (sda_delay > 3) sda_delay = 3; -- cgit v1.2.3-55-g7522