| Message ID | 20221208111910.5.I6edfb3f459662c041563a54e5b7df727c27caaba@changeid (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: dts: qcom: sc7180: Make pazquel360's touchscreen work | expand |
On Thu, Dec 08, 2022 at 11:20:06AM -0800, Douglas Anderson wrote: > The elan touchscreen datasheet says that the reset GPIO only needs to > be asserted for 500us in order to reset the regulator. The problem is > that some boards need a level shifter between the signals on the GPIO > controller and the signals on the touchscreen. All of these extra > components on the line can slow the transition of the signals. On one > board, we measured the reset line and saw that it took almost 1.8ms to > go low. Even after we bumped up the "drive strength" of the signal > from the default 2mA to 8mA we still saw it take 421us for the signal > to go low. > > In order to account for this we let's lengthen the amount of time that nit: s/we let's/we/ || s/we let's/let's/ no need to re-spin just for this > we keep the reset asserted. Let's bump it up from 500us to 5000us. > That's still a relatively short amount of time and is much safer. > > It should be noted that this fixes real problems. Case in point: > 1. The touchscreen power rail may be shared with another device (like > an eDP panel). That means that at probe time power might already be > on. > 2. In probe we grab the reset GPIO and assert it (make it low). > 3. We turn on power (a noop since it was already on). > 4. We wait 500us. > 5. We deassert the reset GPIO. > > With the above case and only a 500us delay we saw only a partial reset > asserted, which is bad. Giving it 5ms is overkill but feels safer in > case someone else has a different level shifter setup. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
On Thu, Dec 08, 2022 at 11:20:06AM -0800, Douglas Anderson wrote: > The elan touchscreen datasheet says that the reset GPIO only needs to > be asserted for 500us in order to reset the regulator. The problem is > that some boards need a level shifter between the signals on the GPIO > controller and the signals on the touchscreen. All of these extra > components on the line can slow the transition of the signals. On one > board, we measured the reset line and saw that it took almost 1.8ms to > go low. Even after we bumped up the "drive strength" of the signal > from the default 2mA to 8mA we still saw it take 421us for the signal > to go low. > > In order to account for this we let's lengthen the amount of time that > we keep the reset asserted. Let's bump it up from 500us to 5000us. > That's still a relatively short amount of time and is much safer. > > It should be noted that this fixes real problems. Case in point: > 1. The touchscreen power rail may be shared with another device (like > an eDP panel). That means that at probe time power might already be > on. > 2. In probe we grab the reset GPIO and assert it (make it low). > 3. We turn on power (a noop since it was already on). > 4. We wait 500us. > 5. We deassert the reset GPIO. > > With the above case and only a 500us delay we saw only a partial reset > asserted, which is bad. Giving it 5ms is overkill but feels safer in > case someone else has a different level shifter setup. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> Applied, thank you.
On Thu, Dec 08, 2022 at 05:38:28PM -0800, Dmitry Torokhov wrote: > On Thu, Dec 08, 2022 at 11:20:06AM -0800, Douglas Anderson wrote: > > The elan touchscreen datasheet says that the reset GPIO only needs to > > be asserted for 500us in order to reset the regulator. The problem is > > that some boards need a level shifter between the signals on the GPIO > > controller and the signals on the touchscreen. All of these extra > > components on the line can slow the transition of the signals. On one > > board, we measured the reset line and saw that it took almost 1.8ms to > > go low. Even after we bumped up the "drive strength" of the signal > > from the default 2mA to 8mA we still saw it take 421us for the signal > > to go low. > > > > In order to account for this we let's lengthen the amount of time that > > we keep the reset asserted. Let's bump it up from 500us to 5000us. > > That's still a relatively short amount of time and is much safer. > > > > It should be noted that this fixes real problems. Case in point: > > 1. The touchscreen power rail may be shared with another device (like > > an eDP panel). That means that at probe time power might already be > > on. > > 2. In probe we grab the reset GPIO and assert it (make it low). > > 3. We turn on power (a noop since it was already on). > > 4. We wait 500us. > > 5. We deassert the reset GPIO. > > > > With the above case and only a 500us delay we saw only a partial reset > > asserted, which is bad. Giving it 5ms is overkill but feels safer in > > case someone else has a different level shifter setup. > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > Applied, thank you. Unapplied ;) I guess we should follow kernel test robot's advise and switch to using usleep_range().
Hi, On Thu, Dec 8, 2022 at 5:48 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > On Thu, Dec 08, 2022 at 05:38:28PM -0800, Dmitry Torokhov wrote: > > On Thu, Dec 08, 2022 at 11:20:06AM -0800, Douglas Anderson wrote: > > > The elan touchscreen datasheet says that the reset GPIO only needs to > > > be asserted for 500us in order to reset the regulator. The problem is > > > that some boards need a level shifter between the signals on the GPIO > > > controller and the signals on the touchscreen. All of these extra > > > components on the line can slow the transition of the signals. On one > > > board, we measured the reset line and saw that it took almost 1.8ms to > > > go low. Even after we bumped up the "drive strength" of the signal > > > from the default 2mA to 8mA we still saw it take 421us for the signal > > > to go low. > > > > > > In order to account for this we let's lengthen the amount of time that > > > we keep the reset asserted. Let's bump it up from 500us to 5000us. > > > That's still a relatively short amount of time and is much safer. > > > > > > It should be noted that this fixes real problems. Case in point: > > > 1. The touchscreen power rail may be shared with another device (like > > > an eDP panel). That means that at probe time power might already be > > > on. > > > 2. In probe we grab the reset GPIO and assert it (make it low). > > > 3. We turn on power (a noop since it was already on). > > > 4. We wait 500us. > > > 5. We deassert the reset GPIO. > > > > > > With the above case and only a 500us delay we saw only a partial reset > > > asserted, which is bad. Giving it 5ms is overkill but feels safer in > > > case someone else has a different level shifter setup. > > > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > > Applied, thank you. > > Unapplied ;) I guess we should follow kernel test robot's advise and > switch to using usleep_range(). Crud. I'll send a v2 right away. -Doug
diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c index 879a4d984c90..377adf89b25c 100644 --- a/drivers/input/touchscreen/elants_i2c.c +++ b/drivers/input/touchscreen/elants_i2c.c @@ -114,7 +114,7 @@ /* calibration timeout definition */ #define ELAN_CALI_TIMEOUT_MSEC 12000 -#define ELAN_POWERON_DELAY_USEC 500 +#define ELAN_POWERON_DELAY_USEC 5000 #define ELAN_RESET_DELAY_MSEC 20 /* FW boot code version */
The elan touchscreen datasheet says that the reset GPIO only needs to be asserted for 500us in order to reset the regulator. The problem is that some boards need a level shifter between the signals on the GPIO controller and the signals on the touchscreen. All of these extra components on the line can slow the transition of the signals. On one board, we measured the reset line and saw that it took almost 1.8ms to go low. Even after we bumped up the "drive strength" of the signal from the default 2mA to 8mA we still saw it take 421us for the signal to go low. In order to account for this we let's lengthen the amount of time that we keep the reset asserted. Let's bump it up from 500us to 5000us. That's still a relatively short amount of time and is much safer. It should be noted that this fixes real problems. Case in point: 1. The touchscreen power rail may be shared with another device (like an eDP panel). That means that at probe time power might already be on. 2. In probe we grab the reset GPIO and assert it (make it low). 3. We turn on power (a noop since it was already on). 4. We wait 500us. 5. We deassert the reset GPIO. With the above case and only a 500us delay we saw only a partial reset asserted, which is bad. Giving it 5ms is overkill but feels safer in case someone else has a different level shifter setup. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/input/touchscreen/elants_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)