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>