This series of patches adds / fixes problems with pazquel360's
touchscreen. A few notes here:
1. Originally the touchscreen was supposed to be added as part of the
first landing of the pazquel360 device tree. ...but the fact that
Yunlong changed email addresses seems to have messed up Bjorn's
scripts. What landed was v3 [1] instead of v5 [2]. The pazquel360 part
of this series is that diff.
2. We delayed sending the fixup till now because soon after the series
landed upstream we found that some laptops were having trouble
initting the touchscreen in cases where the eDP/touchscreen regulator
was left on by the bootloader. We've been struggling to make sense of
all of this. As part of this investigation we landed a85fbd649844
("Input: elants_i2c - properly handle the reset GPIO when power is
off") but that wasn't enough. That fix, together with the fixes in
this series, is enough though.
3. This series is mostly device tree changes with one more change to
the Elan driver. They are fine to land in separate trees. It turns out
that with _just_ the device tree changes things are actually working
OK but the timing is tight, so getting a little extra breathing room
from the Linux driver is nice.
4. Despite the fact that we did debugging here on pazquel360, many of
the changes here are made in general for trogdor devices. I believe
that this will make the timing more correct on those devices even if
we weren't actually seeing problems.
[1] https://lore.kernel.org/r/20220901024827.v3.2.Iea2d2918adfff2825b87d428b5732717425c196f@changeid
[2] https://lore.kernel.org/r/20220923083657.v5.3.Iea2d2918adfff2825b87d428b5732717425c196f@changeid
Changes in v2:
- Fix typo in commit message (Matthias)
- Fix typo in commit message (Matthias)
- udelay -> usleep_range (Patches Robot, Dmitry)
Douglas Anderson (5):
arm64: dts: qcom: sc7180: Bump up trogdor ts_reset_l drive strength
arm64: dts: qcom: sc7180: Add trogdor eDP/touchscreen regulator
off-on-time
arm64: dts: qcom: sc7180: Start the trogdor eDP/touchscreen regulator
on
arm64: dts: qcom: sc7180: Add pazquel360 touschreen
Input: elants_i2c: Delay longer with reset asserted
.../dts/qcom/sc7180-trogdor-homestar.dtsi | 18 ++++++++++++++++
.../qcom/sc7180-trogdor-parade-ps8640.dtsi | 20 ++++++++++++++++++
.../dts/qcom/sc7180-trogdor-pazquel360.dtsi | 21 +++++++++++++++++++
.../dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi | 20 ++++++++++++++++++
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 10 ++++++++-
drivers/input/touchscreen/elants_i2c.c | 4 ++--
6 files changed, 90 insertions(+), 3 deletions(-)
--
2.39.0.rc1.256.g54fd8350bd-goog
In general, the timing diagrams for components specify a minimum time
for power cycling the component. When we remove power from a device we
need to let the device fully discharge and get to a quiescent state
before applying power again. If we power a device on too soon then it
might not have fully powered off and might be in a weird in-between /
invalid state.
eDP panels typically have a time that's at least 500 ms here. You can
see that in Linux's panel-edp driver nearly every device specifies a
"unprepare" time of at least 500 ms. This is a common minimum and the
500 ms is even in the example in the eDP spec.
In Linux, the "panel-edp" driver enforces this delay for its own
control of the regulator, but the "panel-edp" driver can't do anything
about other control of the regulator (for instance, by the touchpanel
driver).
Let's add 500 ms as a board constraint for the regulator that's used
for eDP/touchpanel on trogdor boards. If a given trogdor board stuffs
only panels that can use a shorter time or stuff some panels that need
a larger time then they can manually adjust this timing.
We'll only do this minimum delay for trogdor devices with eDP (ones
that use either bridge chip), not for devices with MIPI panels. MIPI
panels could have similar constraints but the 500 ms isn't necessarily
as standard and there are no known cases where this delay is needed.
For most trogdor boards, this doesn't actually seem to affect anything
when testing against shipping Linux. However, with pazqel360 it seems
that this does make a difference. It seems that the touchscreen on
this board _also_ needs some time for the regulator to discharge. That
time is much less than 500 ms, so we'll just put the eDP panel 500 ms
in there since the board constraint should be the "max" of the
components.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
---
Changes in v2:
- Fix typo in commit message (Matthias)
.../boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi | 12 ++++++++++++
.../boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi | 12 ++++++++++++
2 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi
index ebd6765e2afa..e27a769f8cd4 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi
@@ -26,6 +26,18 @@ pp3300_brij_ps8640: pp3300-brij-ps8640-regulator {
};
};
+/*
+ * ADDITIONS TO FIXED REGULATORS DEFINED IN PARENT DEVICE TREE FILES
+ *
+ * Sort order matches the order in the parent files (parents before children).
+ */
+
+&pp3300_dx_edp {
+ off-on-delay-us = <500000>;
+};
+
+/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
+
&dsi0_out {
remote-endpoint = <&ps8640_in>;
};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi
index 65333709e529..3188788306d0 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi
@@ -7,6 +7,18 @@
#include <dt-bindings/gpio/gpio.h>
+/*
+ * ADDITIONS TO FIXED REGULATORS DEFINED IN PARENT DEVICE TREE FILES
+ *
+ * Sort order matches the order in the parent files (parents before children).
+ */
+
+&pp3300_dx_edp {
+ off-on-delay-us = <500000>;
+};
+
+/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
+
&dsi0_out {
remote-endpoint = <&sn65dsi86_in>;
};
--
2.39.0.rc1.256.g54fd8350bd-goog
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 <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
---
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);
--
2.39.0.rc1.256.g54fd8350bd-goog
The touchscreen was supposed to have been added when pazquel360 first
was added upstream but was missed. Add it now.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
---
(no changes since v1)
.../dts/qcom/sc7180-trogdor-pazquel360.dtsi | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi
index 5702325d0c7b..54b89def8402 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi
@@ -14,6 +14,27 @@ &alc5682 {
realtek,dmic-clk-rate-hz = <2048000>;
};
+ap_ts_pen_1v8: &i2c4 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ ap_ts: touchscreen@10 {
+ compatible = "elan,ekth3915", "elan,ekth3500";
+ reg = <0x10>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_int_l>, <&ts_reset_l>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
+
+ hid-descr-addr = <0x0001>;
+
+ vcc33-supply = <&pp3300_ts>;
+ vccio-supply = <&pp1800_l10a>;
+ reset-gpios = <&tlmm 8 GPIO_ACTIVE_LOW>;
+ };
+};
+
&keyboard_controller {
function-row-physmap = <
MATRIX_KEY(0x00, 0x02, 0) /* T1 */
--
2.39.0.rc1.256.g54fd8350bd-goog
On at least one board (pazquel360) the reset line for the touchscreen
was scoped and found to take almost 2 ms to fall when we drove it
low. This wasn't great because the Linux driver for the touchscreen
(the elants_i2c driver) thinks it can do a 500 us reset pulse. If we
bump the drive strength to 8 mA then the reset line went down in ~421
us.
NOTE: we could apply this fix just for pazquel360, but:
* Probably other trogdor devices have similar timings and it's just
that nobody has noticed it before.
* There are other trogdor boards using the same elan driver that tries
to do 500 us reset pulses.
* Bumping the drive strength to 8mA across the board won't hurt. This
isn't a high speed signal or anything.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index f1defb94d670..ff1c7aa6a722 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -1376,7 +1376,15 @@ ts_reset_l: ts-reset-l-state {
pins = "gpio8";
function = "gpio";
bias-disable;
- drive-strength = <2>;
+
+ /*
+ * The reset GPIO to the touchscreen takes almost 2ms to drop
+ * at the default drive strength. When we bump it up to 8mA it
+ * falls in under 500us. We want this to be fast since the Elan
+ * datasheet (and any drivers written based on it) talk about using
+ * a 500 us reset pulse.
+ */
+ drive-strength = <8>;
};
sdc1_on: sdc1-on-state {
--
2.39.0.rc1.256.g54fd8350bd-goog
Now that we've added the `off-on-delay-us` for the touchpanel
regulator, we can see that we're actually hitting that delay at
bootup. I saw about 200 ms of delay.
Let's avoid that delay by starting the regulator on. We'll only do
this for eDP devices for the time being.
NOTE: we _won't_ do this for homestar. Homestar's panel really likes
to be power cycled. It's why the Linux driver for this panel has a
pm_runtime_put_sync_suspend() when the panel is being unprepared but
the normal panel-edp driver doesn't. It's also why this hardware has a
separate power rail for eDP vs. touchscreen, unlike all the other
trogdor boards. We won't start homestar's regulator on. While this
could mean a slight delay on homestar, it is probably a _correct_
delay. The bootloader might have left the regulator on (it does so in
dev and recovery modes), so if we turned the regulator off at probe
time and we actually hit the delay then we were probably violating T12
in the panel spec.
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
---
(no changes since v1)
.../boot/dts/qcom/sc7180-trogdor-homestar.dtsi | 18 ++++++++++++++++++
.../dts/qcom/sc7180-trogdor-parade-ps8640.dtsi | 8 ++++++++
.../dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi | 8 ++++++++
3 files changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi
index d3cf64c16dcd..b3ba23a88a0b 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-homestar.dtsi
@@ -85,6 +85,24 @@ map1 {
};
};
+/*
+ * ADDITIONS TO FIXED REGULATORS DEFINED IN PARENT DEVICE TREE FILES
+ *
+ * Sort order matches the order in the parent files (parents before children).
+ */
+
+&pp3300_dx_edp {
+ /*
+ * The atna33xc20 really likes to be power cycled to keep it from
+ * getting in a bad state. This is the reason that the touchscreen
+ * rail and eDP rails are separate from each other on homestar (but
+ * not other trogdor devices) Make sure it starts "off" at bootup.
+ */
+ /delete-property/ regulator-boot-on;
+};
+
+/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
+
ap_ts_pen_1v8: &i2c4 {
status = "okay";
clock-frequency = <400000>;
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi
index e27a769f8cd4..5aa7949b5328 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-parade-ps8640.dtsi
@@ -34,6 +34,14 @@ pp3300_brij_ps8640: pp3300-brij-ps8640-regulator {
&pp3300_dx_edp {
off-on-delay-us = <500000>;
+
+ /*
+ * It's nicer to start with this regulator enabled. The
+ * bootloader may have left it on and it's nice not to cause an
+ * extra power cycle of the touchscreen and eDP panel at bootup.
+ * This should help speed bootup because we have off-on-delay-us.
+ */
+ regulator-boot-on;
};
/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi
index 3188788306d0..e52b8776755d 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-ti-sn65dsi86.dtsi
@@ -15,6 +15,14 @@
&pp3300_dx_edp {
off-on-delay-us = <500000>;
+
+ /*
+ * It's nicer to start with this regulator enabled. The
+ * bootloader may have left it on and it's nice not to cause an
+ * extra power cycle of the touchscreen and eDP panel at bootup.
+ * This should help speed bootup because we have off-on-delay-us.
+ */
+ regulator-boot-on;
};
/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
--
2.39.0.rc1.256.g54fd8350bd-goog
Hi,
On Thu, Dec 8, 2022 at 6:21 PM Dmitry Torokhov
<[email protected]> 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 <[email protected]>
> > Reviewed-by: Matthias Kaehlcke <[email protected]>
> > ---
> >
> > 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. :-)
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 <[email protected]>
> Reviewed-by: Matthias Kaehlcke <[email protected]>
> ---
>
> 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
Hi,
On Thu, Dec 8, 2022 at 6:06 PM Douglas Anderson <[email protected]> wrote:
>
> The touchscreen was supposed to have been added when pazquel360 first
> was added upstream but was missed. Add it now.
>
> Signed-off-by: Douglas Anderson <[email protected]>
> Reviewed-by: Matthias Kaehlcke <[email protected]>
> ---
>
> (no changes since v1)
>
> .../dts/qcom/sc7180-trogdor-pazquel360.dtsi | 21 +++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi
> index 5702325d0c7b..54b89def8402 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-pazquel360.dtsi
> @@ -14,6 +14,27 @@ &alc5682 {
> realtek,dmic-clk-rate-hz = <2048000>;
> };
>
> +ap_ts_pen_1v8: &i2c4 {
> + status = "okay";
> + clock-frequency = <400000>;
> +
> + ap_ts: touchscreen@10 {
> + compatible = "elan,ekth3915", "elan,ekth3500";
> + reg = <0x10>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_int_l>, <&ts_reset_l>;
> +
> + interrupt-parent = <&tlmm>;
> + interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
> +
> + hid-descr-addr = <0x0001>;
I happened to re-read this and did a facepalm here. The
'hid-descr-addr' doesn't belong here at all (it's for a totally
different type of touchscreen), but it was there in our downstream
branch (incorrectly) and I just copied it over. I even had noticed it
before, but forgot it yesterday when posting this series.
Just to get things out of the way, I'll post a v3 now. Sorry for the noise.
-Doug