Hi Manuel,
From: *Manuel Lauss* <[email protected]
<mailto:[email protected]>>
Date: Thu, Jul 14, 2011 at 2:26 PM
Subject: [PATCH 3/4] i2c/au1550: increase timeout limit
To: Linux-I2C <[email protected]
<mailto:[email protected]>>, Ben Dooks <[email protected]
<mailto:[email protected]>>
Cc: Manuel Lauss <[email protected]
<mailto:[email protected]>>
The timeout waiting for various events to occur is tailored for
a module clock of 50MHz. On the DB1300 board only 48MHz can be
supplied to the i2c module, which results in the timeout aborting
complex transfers to slaves slightly too early if they employ
for example clock stretching.
With this change the WM8731 codec on the DB1300 board is correctly
detected and initialized.
Signed-off-by: Manuel Lauss <[email protected]
<mailto:[email protected]>>
---
drivers/i2c/busses/i2c-au1550.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-au1550.c
b/drivers/i2c/busses/i2c-au1550.c
index 98ee11a..36d1b29 100644
--- a/drivers/i2c/busses/i2c-au1550.c
+++ b/drivers/i2c/busses/i2c-au1550.c
@@ -344,7 +344,7 @@ i2c_au1550_probe(struct platform_device *pdev)
ret = -EIO;
goto out_map;
}
- priv->xfer_timeout = 200;
+ priv->xfer_timeout = 400;
What is the unit of the timeout. If it is in usec then how is it
dependent on the clock
supplied to the i2c module.
Am I missing something.
priv->adap.nr <http://adap.nr> = pdev->id;
priv->adap.algo = &au1550_algo;
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
<mailto:[email protected]>
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
