Hi, On Wed, Apr 24, 2024 at 1:50 AM Johan Hovold <johan@xxxxxxxxxx> wrote: > > On Tue, Apr 23, 2024 at 01:36:18PM -0700, Doug Anderson wrote: > > On Tue, Apr 23, 2024 at 6:46 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. > > > > Can you provide more details about which devices exactly it shares > > power with? I'm worried that you may be shooting yourself in the foot > > to avoid shooting yourself in the arm. > > > > Specifically, if those other peripherals that may remain powered ever > > power themselves off then you'll end up back-driving the touchscreen > > through the reset line, won't you? Since reset is active low then not > > asserting reset drives the reset line high and, if you power it off, > > it can leach power backwards through the reset line. The > > "goodix,no-reset-during-suspend" property that I added earlier > > specifically worked on systems where the rail was always-on so I could > > guarantee that didn't happen. > > > > From looking at your dts patch it looks like your power _is_ on an > > always-on rail so you should be OK, but it should be documented that > > this only works for always-on rails. > > > > ..also, from your patch description it sounds as if (maybe?) you > > intend to eventually let the rail power off if the trackpad isn't a > > wakeup source. If you eventually plan to do that then you definitely > > need something more complex here... > > No, that's the whole point: the hardware is designed so that the reset > line can be left deasserted by the CPU also when the supply is off. > > The supply in this case is shared with the keyboard and touchpad, but > also some other devices which are not yet fully described. As you > rightly noted, the intention is to allow the supply to eventually be > disabled when none of these devices are enabled as wakeup sources. > > I did not want to get in to too much details on exactly how this > particular reset circuit is designed, but basically you have a pull up > to an always-on 1.8 V rail on the CPU side, a FET level shifter, and a > pull up to the supply voltage on the peripheral side. > > With this design, the reset line can be left deasserted by the CPU > (tri-stated or driven high), but the important part is that the reset > signal that goes into the controller will be pulled to 3.3 V only when > the supply is left on and otherwise it will be connected to ground. Ah, got it. The level shifter isolating things makes sense. > > I guess one last thought is: what do we do if/when someone needs the > > same solution but they want multiple sources of touchscreens, assuming > > we ever get the second-sourcing problem solved well. In that case the > > different touchscreen drivers might have a different idea of how the > > GPIO should be left when the driver exits... > > The second-source problem is arguable a separate one, and as we've > discussed in the past, the current approach of describing both devices > in the devicetree only works when the devices are truly compatible in > terms of external resources (supplies, gpios, pinconfig). For anything > more complex, we need a more elaborate implementation. > > In this case it should not be a problem, though, as the reset circuit > should have the same properties regardless of which controller you > connect (e.g. both nodes would have the 'no-reset-on-power-off' > property). The reset circuitry may be the same, but the properties of the touchscreen might not be. It would be easy to imagine a different touchscreen that consumes less power when held in reset. In any case, not a problem we need to solve right now. -Doug
