Hi Johan,
On Tue, Apr 23, 2024 at 8:47 AM Johan Hovold <johan+linaro@xxxxxxxxxx> wrote:
>
> The Elan eKTH5015M touch controller on the X13s requires a 300 ms delay
> before sending commands after having deasserted reset during power on.
>
> This series switches the X13s devicetree to use the Elan specific
> binding so that the OS can determine the required power-on sequence and
> make sure that the controller is always detected during boot. [1]
>
> The Elan hid-i2c driver currently asserts reset unconditionally during
> suspend, which does not work on the X13s where the touch controller
> supply is shared with other peripherals that may remain powered. Holding
> the controller in reset can increase power consumption and also leaks
> current through the reset circuitry pull ups.
>
> Note that the latter also affects X13s variants where the touchscreen is
> not populated as the driver also exits probe() with reset asserted.
>
> Fix this by adding a new 'no-reset-on-power-off' devicetree property
> which can be used by the OS to determine when reset needs to be asserted
> on power down and when it safe and desirable to leave it deasserted.
>
> I tried to look for drivers that had already addressed this but it was
> only after I finished implementing this that I noticed Doug's reference
> to commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the reset line to
> true state of the regulator"), which tried to solve a related problem.
>
> That commit has since been reverted but ultimately resulted in commit
> 7607f12ba735 ("HID: i2c-hid: goodix: Add support for
> "goodix,no-reset-during-suspend" property") being merged to handle the
> related case where the touch controller supply is always on.
>
> The implementation is very similar, but I decided to use the slightly
> more generic 'no-reset-on-power-off' property name after considering a
> number of alternatives (including trying to describe the hardware
> configuration in the name). (And as this is not vendor specific, I left
> out the prefix.)
>
> Note that my X13s does not have a touchscreen, but I have done partial
> verification of the implementation using that machine and the sc8280xp
> CRD reference design. Bjorn has promised to help out with final
> verification on an X13s with a touchscreen.
>
> The devicetree changes are expected to go in through the Qualcomm tree
> once the binding and driver updates have been merged.
>
> Johan
>
>
> [1] The reset signal is currently deasserted using the pin configuration
> and the controller would be detected if probe is deferred or if user
> space triggers a reprobe through sysfs.
>
>
> Johan Hovold (6):
> dt-bindings: HID: i2c-hid: add dedicated Ilitek ILI2901 schema
> dt-bindings: HID: i2c-hid: elan: add Elan eKTH5015M
> dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property
> HID: i2c-hid: elan: fix reset suspend current leakage
> arm64: dts: qcom: sc8280xp-x13s: fix touchscreen power on
> arm64: dts: qcom: sc8280xp-crd: use external pull up for touch reset
>
> .../bindings/input/elan,ekth6915.yaml | 20 ++++--
> .../bindings/input/ilitek,ili2901.yaml | 66 +++++++++++++++++++
> arch/arm64/boot/dts/qcom/sc8280xp-crd.dts | 3 +-
> .../qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 15 +++--
> drivers/hid/i2c-hid/i2c-hid-of-elan.c | 37 ++++++++---
> 5 files changed, 118 insertions(+), 23 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/ilitek,ili2901.yaml
>
> --
> 2.43.2
>
>
I thought that I'd purchased a Thinkpad X13s without touchscreen, but
it turns out that I do have one, and since I do, I was able to test
this patchset, and it works on mine.
Tested-by: Steev Klimaszewski <steev@xxxxxxxx>
