Hi Dmitry
On 2020/08/28 17:19, Dmitry Osipenko wrote:
21.08.2020 11:22, Jiada Wang пишет:
From: Nick Dyer <nick.d...@itdev.co.uk>
Some maXTouch chips (eg mXT1386) will not respond on the first I2C request
when they are in a sleep state. It must be retried after a delay for the
chip to wake up.
Signed-off-by: Nick Dyer <nick.d...@itdev.co.uk>
Acked-by: Yufeng Shen <mile...@chromium.org>
(cherry picked from ndyer/linux/for-upstream commit
63fd7a2cd03c3a572a5db39c52f4856819e1835d)
[gdavis: Forward port and fix conflicts.]
Signed-off-by: George G. Davis <george_da...@mentor.com>
Signed-off-by: Jiada Wang <jiada_w...@mentor.com>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 45 ++++++++++++++++--------
1 file changed, 30 insertions(+), 15 deletions(-)
Hello, Jiada!
I tested this patch on Acer A500 that has mXT1386 controller which
requires the I2C retrying and everything working good, no problems
spotted! Touchscreen doesn't work without this patch!
Tested-by: Dmitry Osipenko <dig...@gmail.com>
I have one minor comment, please see it below!
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
b/drivers/input/touchscreen/atmel_mxt_ts.c
index a2189739e30f..e93eda1f3d59 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -196,6 +196,7 @@ enum t100_type {
#define MXT_CRC_TIMEOUT 1000 /* msec */
#define MXT_FW_RESET_TIME 3000 /* msec */
#define MXT_FW_CHG_TIMEOUT 300 /* msec */
+#define MXT_WAKEUP_TIME 25 /* msec */
/* Command to unlock bootloader */
#define MXT_UNLOCK_CMD_MSB 0xaa
@@ -626,6 +627,7 @@ static int __mxt_read_reg(struct i2c_client *client,
struct i2c_msg xfer[2];
u8 buf[2];
int ret;
+ bool retry = false;
buf[0] = reg & 0xff;
buf[1] = (reg >> 8) & 0xff;
@@ -642,17 +644,22 @@ static int __mxt_read_reg(struct i2c_client *client,
xfer[1].len = len;
xfer[1].buf = val;
- ret = i2c_transfer(client->adapter, xfer, 2);
- if (ret == 2) {
- ret = 0;
- } else {
- if (ret >= 0)
- ret = -EIO;
- dev_err(&client->dev, "%s: i2c transfer failed (%d)\n",
- __func__, ret);
+retry_read:
+ ret = i2c_transfer(client->adapter, xfer, ARRAY_SIZE(xfer));
+ if (ret != ARRAY_SIZE(xfer)) {
Is it really possible to get a positive ret != 2 from i2c_transfer()?
Maybe it's better to keep the old code behaviour by returning the "ret"
value directly if it's not equal to ARRAY_SIZE(xfer)?
I think, theoretically i2c_transfer() may return positive value but !=
number to transfer,
original behavior is,
when ret >= 0, it returns -EIO, when ret < 0, it just returns ret,
current behavior is, when ret != 2, it returns -EIO, after retry.
I am OK to change the behavior exactly as same original one.
Thanks,
Jiada
