HSI2C_MASTER_ST_LOSE state is not documented properly, extensive tests
show that hardware is usually able to recover from this state without
interrupting the transfer. On the other side enforcing transfer repetition
in such case does not help in many situations, especially on busy systems
and causes -EAGAIN and -ETIMEOUT errors. Moreover documentation says that
such state can be caused by slave clock stretching, and should not be treated
as an error.
Signed-off-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx>
---
drivers/i2c/busses/i2c-exynos5.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 4ca43980e2ed..d579b45b3092 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -445,12 +445,6 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void *dev_id)
i2c->state = -ETIMEDOUT;
goto stop;
}
-
- trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
- if ((trans_status & HSI2C_MASTER_ST_MASK) == HSI2C_MASTER_ST_LOSE) {
- i2c->state = -EAGAIN;
- goto stop;
- }
} else if (int_status & HSI2C_INT_I2C) {
trans_status = readl(i2c->regs + HSI2C_TRANS_STATUS);
if (trans_status & HSI2C_NO_DEV_ACK) {
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
