On Fri, Nov 17, 2017 at 7:00 PM, Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > On Fri, Nov 17, 2017 at 06:01:27PM +0800, Chris Chiu wrote: >> Hi Mika, >> Here's the full dmesg log you need. The touchpad stop reporting at >> the last of the log. >> https://gist.github.com/mschiu77/a0b8d24a586a228c55eca30c87c71d41 > > Thanks! > > I did not spot anything suspicious in the i2c-hid initialization. When > the issue happens, can you check what the pin state is and if it changes > when you use the touchpad? If I read your ACPI tables right, something > like this: > > # grep GPIO_18 /sys/kernel/debug/pinctrl/INT3452:00/pins > > (it could be another INT3452:* device as well). > > The GPIO line should be high and when the touchpad is pressed it should > go low. > > Then another thing, if you unload i2c-hid and load it back, does it > start working again? > > # modprobe -r i2c-hid > # modprobe i2c-hid Yup. We did the same inspection on /sys/kernel/debug/pinctrl/INT3452:00/pins before and after the touchpad stop working. Before touchpad stop working, most of the results would be pin 18 (GPIO_18) GPIO 0x40900102 0x00024075 After touchpad stop working, the result would always be pin 18 (GPIO_18) GPIO 0x40900100 0x00024075 The only difference is the GPIO level value. It is always low after touchpad stop working (and no interrupt observed since then). And, it won't come back event we reload the i2c-hid. It keeps failing on reset. The dmesg is as following https://gist.github.com/mschiu77/b9250d5e7774f2b01898f1949675185d -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html