On Fri, Jan 26, 2024 at 06:53:46AM -0800, Bjorn Andersson wrote: > On Fri, Jan 26, 2024 at 03:31:02PM +0100, Johan Hovold wrote: > > On Fri, Jan 26, 2024 at 01:02:32PM +0000, Daniel Thompson wrote: > > > In short it looks like the delays make the difference and, even a short > > > delay, can fix the problem. > > > > Right, but since the suppliers are left enabled by the bootloader (and > > never disabled by the kernel), that only begs the question of why this > > makes a difference. > > You're right, the supply is kept on by other things, so this isn't the > problem. > > > Without the delay, the other HID devices are probing (successfully) > > slightly before, but essentially in parallel with the touchscreen while > > using the same resources. Is that causing trouble somehow? > > The difference to those other HID devices is GPIO 99 - the reset pin, > which is configured pull down input from boot - i.e. the chip is held in > reset. > > When the HID device is being probed, pinctrl applies &ts0_default starts > driving it high, bringing the device out of reset. But insufficient time > is given for the chip to come up so the I2C read fails. Ah, that's it. You should drop that 'output-high' from the pin config as part of this patch to avoid toggling the reset line twice at boot. Looks like we have the same problem on the CRD as well. There the touchscreen still works, possibly because it has been enabled by the boot firmware or simply because that touchscreen can handle a shorter delay. Where exactly did you find those delay values in the ACPI tables? I couldn't seem to find anything in the decompiled DSDT. > If you later try to probe again, 200ms has elapsed since the reset was > deasserted (driven high). Right. Johan
