| Message ID | 20180823231013.254037-1-dbasehore@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Input: elants_i2c - Fix sw reset delays | expand |
Hi Derek, On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: > We only need to wait 10ms instead of 30ms before starting fastboot or > sending IAP on the touchscreen. Also, instead of delaying everytime > sw_reset is called, this delays 10ms in the function that starts > fastboot. There's also an explicit 20ms delay before sending IAP when > updating the firmware, so no additional delay is needed there. This > change also has the benefit of not delaying when wakeup is enabled > during suspend. This is because sw_reset is called, yet fastboot > isn't. > > Change-Id: I9e3019720186ba0023891fafeb4fe3d2510e454b This is not needed ;) > Signed-off-by: Derek Basehore <dbasehore@chromium.org> > --- > drivers/input/touchscreen/elants_i2c.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c > index d21ca39b0fdb..18ce04ba0173 100644 > --- a/drivers/input/touchscreen/elants_i2c.c > +++ b/drivers/input/touchscreen/elants_i2c.c > @@ -284,12 +284,6 @@ static int elants_i2c_sw_reset(struct i2c_client *client) > return error; > } > > - /* > - * We should wait at least 10 msec (but no more than 40) before > - * sending fastboot or IAP command to the device. > - */ > - msleep(30); > - > return 0; > } > > @@ -500,6 +494,12 @@ static int elants_i2c_fastboot(struct i2c_client *client) > const u8 boot_cmd[] = { 0x4D, 0x61, 0x69, 0x6E }; > int error; > > + /* > + * We should wait at least 10 msec (but no more than 40) before sending > + * fastboot command to the device. > + */ > + usleep_range(10 * 1000, 11 * 1000); > + > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); > if (error) { > dev_err(&client->dev, "boot failed: %d\n", error); > @@ -643,6 +643,10 @@ static int elants_i2c_do_update_firmware(struct i2c_client *client, > dev_err(&client->dev, "Failed close idle: %d\n", error); > msleep(60); > elants_i2c_sw_reset(client); > + /* > + * We should wait at least 10 msec (but no more than 40) before > + * sending IAP command to the device. > + */ > msleep(20); So the original comment was talking about timing on fastboot or IAP command, but the original code had 50 msec wait here (30 from elants_i2c_sw_reset plus the 20), thus already violating 40 msec rule for IAP. Unless Elan folks can confirm it is OK to reduce the wait here I'd prefer we kept it at 50. Firmware update is does not happen that often anyway. Thanks.
Let's add Elan folks to the discussion. On Thu, Aug 23, 2018 at 04:30:28PM -0700, Dmitry Torokhov wrote: > Hi Derek, > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: > > We only need to wait 10ms instead of 30ms before starting fastboot or > > sending IAP on the touchscreen. Also, instead of delaying everytime > > sw_reset is called, this delays 10ms in the function that starts > > fastboot. There's also an explicit 20ms delay before sending IAP when > > updating the firmware, so no additional delay is needed there. This > > change also has the benefit of not delaying when wakeup is enabled > > during suspend. This is because sw_reset is called, yet fastboot > > isn't. > > > > Change-Id: I9e3019720186ba0023891fafeb4fe3d2510e454b > > This is not needed ;) > > > Signed-off-by: Derek Basehore <dbasehore@chromium.org> > > --- > > drivers/input/touchscreen/elants_i2c.c | 16 ++++++++++------ > > 1 file changed, 10 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c > > index d21ca39b0fdb..18ce04ba0173 100644 > > --- a/drivers/input/touchscreen/elants_i2c.c > > +++ b/drivers/input/touchscreen/elants_i2c.c > > @@ -284,12 +284,6 @@ static int elants_i2c_sw_reset(struct i2c_client *client) > > return error; > > } > > > > - /* > > - * We should wait at least 10 msec (but no more than 40) before > > - * sending fastboot or IAP command to the device. > > - */ > > - msleep(30); > > - > > return 0; > > } > > > > @@ -500,6 +494,12 @@ static int elants_i2c_fastboot(struct i2c_client *client) > > const u8 boot_cmd[] = { 0x4D, 0x61, 0x69, 0x6E }; > > int error; > > > > + /* > > + * We should wait at least 10 msec (but no more than 40) before sending > > + * fastboot command to the device. > > + */ > > + usleep_range(10 * 1000, 11 * 1000); > > + > > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); > > if (error) { > > dev_err(&client->dev, "boot failed: %d\n", error); > > @@ -643,6 +643,10 @@ static int elants_i2c_do_update_firmware(struct i2c_client *client, > > dev_err(&client->dev, "Failed close idle: %d\n", error); > > msleep(60); > > elants_i2c_sw_reset(client); > > + /* > > + * We should wait at least 10 msec (but no more than 40) before > > + * sending IAP command to the device. > > + */ > > msleep(20); > > So the original comment was talking about timing on fastboot or IAP > command, but the original code had 50 msec wait here (30 from > elants_i2c_sw_reset plus the 20), thus already violating 40 msec rule > for IAP. Unless Elan folks can confirm it is OK to reduce the wait here > I'd prefer we kept it at 50. Firmware update is does not happen that > often anyway. > > Thanks. > > -- > Dmitry
For real now... On Thu, Aug 23, 2018 at 04:32:11PM -0700, Dmitry Torokhov wrote: > Let's add Elan folks to the discussion. > > On Thu, Aug 23, 2018 at 04:30:28PM -0700, Dmitry Torokhov wrote: > > Hi Derek, > > > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: > > > We only need to wait 10ms instead of 30ms before starting fastboot or > > > sending IAP on the touchscreen. Also, instead of delaying everytime > > > sw_reset is called, this delays 10ms in the function that starts > > > fastboot. There's also an explicit 20ms delay before sending IAP when > > > updating the firmware, so no additional delay is needed there. This > > > change also has the benefit of not delaying when wakeup is enabled > > > during suspend. This is because sw_reset is called, yet fastboot > > > isn't. > > > > > > Change-Id: I9e3019720186ba0023891fafeb4fe3d2510e454b > > > > This is not needed ;) > > > > > Signed-off-by: Derek Basehore <dbasehore@chromium.org> > > > --- > > > drivers/input/touchscreen/elants_i2c.c | 16 ++++++++++------ > > > 1 file changed, 10 insertions(+), 6 deletions(-) > > > > > > diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c > > > index d21ca39b0fdb..18ce04ba0173 100644 > > > --- a/drivers/input/touchscreen/elants_i2c.c > > > +++ b/drivers/input/touchscreen/elants_i2c.c > > > @@ -284,12 +284,6 @@ static int elants_i2c_sw_reset(struct i2c_client *client) > > > return error; > > > } > > > > > > - /* > > > - * We should wait at least 10 msec (but no more than 40) before > > > - * sending fastboot or IAP command to the device. > > > - */ > > > - msleep(30); > > > - > > > return 0; > > > } > > > > > > @@ -500,6 +494,12 @@ static int elants_i2c_fastboot(struct i2c_client *client) > > > const u8 boot_cmd[] = { 0x4D, 0x61, 0x69, 0x6E }; > > > int error; > > > > > > + /* > > > + * We should wait at least 10 msec (but no more than 40) before sending > > > + * fastboot command to the device. > > > + */ > > > + usleep_range(10 * 1000, 11 * 1000); > > > + > > > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); > > > if (error) { > > > dev_err(&client->dev, "boot failed: %d\n", error); > > > @@ -643,6 +643,10 @@ static int elants_i2c_do_update_firmware(struct i2c_client *client, > > > dev_err(&client->dev, "Failed close idle: %d\n", error); > > > msleep(60); > > > elants_i2c_sw_reset(client); > > > + /* > > > + * We should wait at least 10 msec (but no more than 40) before > > > + * sending IAP command to the device. > > > + */ > > > msleep(20); > > > > So the original comment was talking about timing on fastboot or IAP > > command, but the original code had 50 msec wait here (30 from > > elants_i2c_sw_reset plus the 20), thus already violating 40 msec rule > > for IAP. Unless Elan folks can confirm it is OK to reduce the wait here > > I'd prefer we kept it at 50. Firmware update is does not happen that > > often anyway. > > > > Thanks. > > > > -- > > Dmitry > > -- > Dmitry
Hi Derek, > > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: > > > > We only need to wait 10ms instead of 30ms before starting fastboot or > > > > sending IAP on the touchscreen. Also, instead of delaying everytime > > > > sw_reset is called, this delays 10ms in the function that starts > > > > fastboot. There's also an explicit 20ms delay before sending IAP when > > > > updating the firmware, so no additional delay is needed there. This > > > > change also has the benefit of not delaying when wakeup is enabled > > > > during suspend. This is because sw_reset is called, yet fastboot > > > > isn't. ... > > > > - /* > > > > - * We should wait at least 10 msec (but no more than 40) before > > > > - * sending fastboot or IAP command to the device. > > > > - */ > > > > - msleep(30); > > > > - moving from 30 to 0 is a bit alarming... what does the datasheet say? Sometimes delays are implicit in the system where you are testing the driver, so that without any msleep it might work in your system but it might not on others. > + /* > + * We should wait at least 10 msec (but no more than 40) before > + * sending IAP command to the device. > + */ > msleep(20); I agree though that it's not nice to wait twice here (even though as Dmitry says it doesn't hurt so much). Wouldn't it make more sense to remove this msleep instead? This way... > + /* > + * We should wait at least 10 msec (but no more than 40) before sending > + * fastboot command to the device. > + */ > + usleep_range(10 * 1000, 11 * 1000); > + > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); ... you do not need to add an extra sleep here. Andi
On Fri, Aug 24, 2018 at 4:07 PM dbasehore . <dbasehore@chromium.org> wrote: > > > > On Fri, Aug 24, 2018 at 1:49 AM Andi Shyti <andi@etezian.org> wrote: >> >> Hi Derek, >> >> > > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: >> > > > > We only need to wait 10ms instead of 30ms before starting fastboot or >> > > > > sending IAP on the touchscreen. Also, instead of delaying everytime >> > > > > sw_reset is called, this delays 10ms in the function that starts >> > > > > fastboot. There's also an explicit 20ms delay before sending IAP when >> > > > > updating the firmware, so no additional delay is needed there. This >> > > > > change also has the benefit of not delaying when wakeup is enabled >> > > > > during suspend. This is because sw_reset is called, yet fastboot >> > > > > isn't. >> >> ... >> >> > > > > - /* >> > > > > - * We should wait at least 10 msec (but no more than 40) before >> > > > > - * sending fastboot or IAP command to the device. >> > > > > - */ >> > > > > - msleep(30); >> > > > > - >> >> moving from 30 to 0 is a bit alarming... what does the datasheet >> say? > > > We're moving from 30msec to 10msec. We used to do this in an older kernel. > >> >> >> Sometimes delays are implicit in the system where you are testing >> the driver, so that without any msleep it might work in your >> system but it might not on others. >> >> > + /* >> > + * We should wait at least 10 msec (but no more than 40) before >> > + * sending IAP command to the device. >> > + */ >> > msleep(20); >> >> I agree though that it's not nice to wait twice here (even though >> as Dmitry says it doesn't hurt so much). Wouldn't it make more >> sense to remove this msleep instead? >> This way... > > > We still need this if the delay is removed from the sw_reset function. We have a total of 20msecs delayed between sw_reset and sending IAP in our old kernel which should be well tested. There seems to be no reason why the delays increased. > >> >> >> > + /* >> > + * We should wait at least 10 msec (but no more than 40) before sending >> > + * fastboot command to the device. >> > + */ >> > + usleep_range(10 * 1000, 11 * 1000); >> > + >> > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); >> >> ... you do not need to add an extra sleep here. > > > I added it here since I removed the 30msec sleep in sw_reset. This prevents us from sleeping on resume when the touch controller is already on for wake up capabilities. This is the same delay that we have in our old 3.8 kernel, so it's pretty well tested and shipped in production. > >> >> >> Andi Resending since it seems my plain text setting was removed...
Hi Derek, next time, could you please avoid using html mails when replying to the mailing list? They are not clear. On Fri, Aug 24, 2018 at 04:07:41PM -0700, dbasehore . wrote: > > > On Fri, Aug 24, 2018 at 1:49 AM Andi Shyti <andi@etezian.org> wrote: > > Hi Derek, > > > > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: > > > > > We only need to wait 10ms instead of 30ms before starting fastboot > or > > > > > sending IAP on the touchscreen. Also, instead of delaying everytime > > > > > sw_reset is called, this delays 10ms in the function that starts > > > > > fastboot. There's also an explicit 20ms delay before sending IAP > when > > > > > updating the firmware, so no additional delay is needed there. This > > > > > change also has the benefit of not delaying when wakeup is enabled > > > > > during suspend. This is because sw_reset is called, yet fastboot > > > > > isn't. > > ... > > > > > > - /* > > > > > - * We should wait at least 10 msec (but no more than 40) > before > > > > > - * sending fastboot or IAP command to the device. > > > > > - */ > > > > > - msleep(30); > > > > > - > > moving from 30 to 0 is a bit alarming... what does the datasheet > say? > > > We're moving from 30msec to 10msec. We used to do this in an older kernel. That's not what you are saying in your commit message: "... This change also has the benefit of not delaying when wakeup is enabled during suspend... " and indeed, in resume the "elants_i2c_sw_reset()" function would be called without any msleep. Or am I missing something? Would it be correct based on the datasheet? > > > > Sometimes delays are implicit in the system where you are testing > the driver, so that without any msleep it might work in your > system but it might not on others. > > > + /* > > + * We should wait at least 10 msec (but no more than 40) > before > > + * sending IAP command to the device. > > + */ > > msleep(20); > > I agree though that it's not nice to wait twice here (even though > as Dmitry says it doesn't hurt so much). Wouldn't it make more > sense to remove this msleep instead? > This way... > > > We still need this if the delay is removed from the sw_reset function. We have > a total of 20msecs delayed between sw_reset and sending IAP in our old kernel > which should be well tested. There seems to be no reason why the delays > increased. Yes, that's what I'm saying, removing this msleep to me looks more correct than removing it from sw_reset(). > > + /* > > + * We should wait at least 10 msec (but no more than 40) before > sending > > + * fastboot command to the device. > > + */ > > + usleep_range(10 * 1000, 11 * 1000); > > + > > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); > > ... you do not need to add an extra sleep here. > > > I added it here since I removed the 30msec sleep in sw_reset. This prevents us > from sleeping on resume when the touch controller is already on for wake up > capabilities. This is the same delay that we have in our old 3.8 kernel, so > it's pretty well tested and shipped in production. And here we fall in my first question (and also Dmitry's concern), Are we sure we don't need to sleep after resume? Again, what does the datasheet say? I don't know the answer, you might be right, but I need to know why you are removing the sleep after resume and why, instead, the original developer added it there. Two more nitpicks on this patch: 1. by adding the usleep_range() outside from the elants_i2c_sw_reset() function, to another developer reading the code, might not really look clear why we are waiting. The comment you copy pasted does not, indeed, refer that we are waiting because a reset has been performed and we need to wait for the _reset time_ before sending IAP commands. 2. this is a matter of taste: to me "10000" looks more clear than "10 * 1000", which doesn't add any better readability of the number itself. Thanks, Andi
On Mon, Aug 27, 2018 at 4:52 AM Andi Shyti <andi@etezian.org> wrote: > > Hi Derek, > > next time, could you please avoid using html mails when replying > to the mailing list? They are not clear. Sorry, my plain text setting was reset for some reason. > > On Fri, Aug 24, 2018 at 04:07:41PM -0700, dbasehore . wrote: > > > > > > On Fri, Aug 24, 2018 at 1:49 AM Andi Shyti <andi@etezian.org> wrote: > > > > Hi Derek, > > > > > > > On Thu, Aug 23, 2018 at 04:10:13PM -0700, Derek Basehore wrote: > > > > > > We only need to wait 10ms instead of 30ms before starting fastboot > > or > > > > > > sending IAP on the touchscreen. Also, instead of delaying everytime > > > > > > sw_reset is called, this delays 10ms in the function that starts > > > > > > fastboot. There's also an explicit 20ms delay before sending IAP > > when > > > > > > updating the firmware, so no additional delay is needed there. This > > > > > > change also has the benefit of not delaying when wakeup is enabled > > > > > > during suspend. This is because sw_reset is called, yet fastboot > > > > > > isn't. > > > > ... > > > > > > > > - /* > > > > > > - * We should wait at least 10 msec (but no more than 40) > > before > > > > > > - * sending fastboot or IAP command to the device. > > > > > > - */ > > > > > > - msleep(30); > > > > > > - > > > > moving from 30 to 0 is a bit alarming... what does the datasheet > > say? > > > > > > We're moving from 30msec to 10msec. We used to do this in an older kernel. > > That's not what you are saying in your commit message: We still delay 10ms before fastboot. That's what this is referring to. In the change, 3 delays are addressed: fastboot, IAP, and wakeup enabled. The fastboot delay is changed to 10ms. The IAP delay is changed to 20ms, and the delay when wakeup is enabled is removed. > > "... This change also has the benefit of not delaying when > wakeup is enabled during suspend... " > > and indeed, in resume the "elants_i2c_sw_reset()" function would > be called without any msleep. Or am I missing something? Would > it be correct based on the datasheet? I was told it was correct to do this, but I wonder if something can race if we don't delay? I don't doubt that nothing in the resume callback needs that delay since we just enable the irq then leave the function. There might be something like calibration that does need the msleep after sw_reset. I'll need to check if we only need to delay after sw reset for just fastboot and IAP (as the code comment indicated) or for any i2c write. > > > > > > > > > Sometimes delays are implicit in the system where you are testing > > the driver, so that without any msleep it might work in your > > system but it might not on others. > > > > > + /* > > > + * We should wait at least 10 msec (but no more than 40) > > before > > > + * sending IAP command to the device. > > > + */ > > > msleep(20); > > > > I agree though that it's not nice to wait twice here (even though > > as Dmitry says it doesn't hurt so much). Wouldn't it make more > > sense to remove this msleep instead? > > This way... > > > > > > We still need this if the delay is removed from the sw_reset function. We have > > a total of 20msecs delayed between sw_reset and sending IAP in our old kernel > > which should be well tested. There seems to be no reason why the delays > > increased. > > Yes, that's what I'm saying, removing this msleep to me looks > more correct than removing it from sw_reset(). > > > > + /* > > > + * We should wait at least 10 msec (but no more than 40) before > > sending > > > + * fastboot command to the device. > > > + */ > > > + usleep_range(10 * 1000, 11 * 1000); > > > + > > > error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); > > > > ... you do not need to add an extra sleep here. > > > > > > I added it here since I removed the 30msec sleep in sw_reset. This prevents us > > from sleeping on resume when the touch controller is already on for wake up > > capabilities. This is the same delay that we have in our old 3.8 kernel, so > > it's pretty well tested and shipped in production. > > And here we fall in my first question (and also Dmitry's > concern), Are we sure we don't need to sleep after resume? Again, > what does the datasheet say? > > I don't know the answer, you might be right, but I need to know > why you are removing the sleep after resume and why, instead, > the original developer added it there. > > Two more nitpicks on this patch: > > 1. by adding the usleep_range() outside from the > elants_i2c_sw_reset() function, to another developer reading the > code, might not really look clear why we are waiting. The > comment you copy pasted does not, indeed, refer that we are > waiting because a reset has been performed and we need to wait > for the _reset time_ before sending IAP commands. > > 2. this is a matter of taste: to me "10000" looks more clear than > "10 * 1000", which doesn't add any better readability of the > number itself. > > Thanks, > Andi
diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c index d21ca39b0fdb..18ce04ba0173 100644 --- a/drivers/input/touchscreen/elants_i2c.c +++ b/drivers/input/touchscreen/elants_i2c.c @@ -284,12 +284,6 @@ static int elants_i2c_sw_reset(struct i2c_client *client) return error; } - /* - * We should wait at least 10 msec (but no more than 40) before - * sending fastboot or IAP command to the device. - */ - msleep(30); - return 0; } @@ -500,6 +494,12 @@ static int elants_i2c_fastboot(struct i2c_client *client) const u8 boot_cmd[] = { 0x4D, 0x61, 0x69, 0x6E }; int error; + /* + * We should wait at least 10 msec (but no more than 40) before sending + * fastboot command to the device. + */ + usleep_range(10 * 1000, 11 * 1000); + error = elants_i2c_send(client, boot_cmd, sizeof(boot_cmd)); if (error) { dev_err(&client->dev, "boot failed: %d\n", error); @@ -643,6 +643,10 @@ static int elants_i2c_do_update_firmware(struct i2c_client *client, dev_err(&client->dev, "Failed close idle: %d\n", error); msleep(60); elants_i2c_sw_reset(client); + /* + * We should wait at least 10 msec (but no more than 40) before + * sending IAP command to the device. + */ msleep(20); error = elants_i2c_send(client, enter_iap, sizeof(enter_iap)); }
We only need to wait 10ms instead of 30ms before starting fastboot or sending IAP on the touchscreen. Also, instead of delaying everytime sw_reset is called, this delays 10ms in the function that starts fastboot. There's also an explicit 20ms delay before sending IAP when updating the firmware, so no additional delay is needed there. This change also has the benefit of not delaying when wakeup is enabled during suspend. This is because sw_reset is called, yet fastboot isn't. Change-Id: I9e3019720186ba0023891fafeb4fe3d2510e454b Signed-off-by: Derek Basehore <dbasehore@chromium.org> --- drivers/input/touchscreen/elants_i2c.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)