Message ID | 20221208180603.v2.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 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@chromium.org> > Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > --- > > 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.
Hi, On Thu, Dec 8, 2022 at 6:21 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > 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@chromium.org> > > Reviewed-by: Matthias Kaehlcke <mka@chromium.org> > > --- > > > > 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(-) Ah, right. I posted it against the Qualcomm tree which, of course, doesn't have the previous patch I posted to this driver. Thanks for fixing it up. :-)
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);