On Thu, Dec 08, 2022 at 06:06:12PM -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 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. > > Note that bumping up the delay to 5000 means that some configs yell > about using udelay(). We'll change to using usleep_range(). We give a > small range here because: > - This isn't a delay that happens very often so we don't need to worry > about giving a big range to allow for power efficiency. > - usleep_range() is known to almost always pick the upper bound and > delay that long and we really don't want to slow down the power on > of the touchscreen that much. > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > Reviewed-by: Matthias Kaehlcke <mka@xxxxxxxxxxxx> > --- > > Changes in v2: > - Fix typo in commit message (Matthias) > - udelay -> usleep_range (Patches Robot, Dmitry) > > drivers/input/touchscreen/elants_i2c.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c > index 879a4d984c90..192d543e5aa9 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 */ > @@ -1352,7 +1352,7 @@ static int elants_i2c_power_on(struct elants_data *ts) > * We need to wait a bit after powering on controller before > * we are allowed to release reset GPIO. > */ > - udelay(ELAN_POWERON_DELAY_USEC); > + usleep_range(ELAN_POWERON_DELAY_USEC, ELAN_POWERON_DELAY_USEC + 100); > > release_reset_gpio: > gpiod_set_value_cansleep(ts->reset_gpio, 0); This gives me conflict because this label is gone in my tree, so I adjusted for context and applied. Thanks. -- Dmitry
