On Thu, Oct 01, 2020 at 10:57:40PM +0200, Linus Walleij wrote:
Sorry for top posting, but I want to page some people. I do not know anything about ACPI, but Hans de Goede is really good with this kind of things and could possibly provide some insight.
Thank you for introducing Hans de Goede to me!
Yours, Linus Walleij On Thu, Oct 1, 2020 at 3:23 PM Coiby Xu <coiby.xu@xxxxxxxxx> wrote:Hi, I'm trying to fix broken touchpads [1] for a new laptop model Legion-5 15ARH05 which is shipped with two different touchpads, i.e., ElAN and Synaptics. For the ELAN touchpad, the kernel receives no interrupts to be informed of new data from the touchpad. For the Synaptics touchpad, only 7 interrupts are received per second which makes the touchpad completely unusable. Based on current observations, pinctrl-amd seems to be the most suspicious cause. Why do I think pinctrl-amd smells the most suspicious? ====================================================== This laptop model has the following hardware configurations specified via ACPI, - The touchpad's data interrupt line is connected to pin#130 of a GPIO chip GpioInt (Level, ActiveLow, ExclusiveAndWake, PullUp, 0x0000, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x0082 } - This GPIO chip (HID: AMDI0030) which is assigned with IRQ#7 has its common interrupt output line connected to one IO-APIC's pin#7 Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) { 0x00000007, } I add some code to kernel to poll the status of the GPIO chip's pin#130 and IO-APIc's pin#7 every 1ms when I move my finger on the surface of the Synaptics touchpad continuously for about 1s. During the process of I move my finger, most of the time, - GPIO chip's pin#130: low input, interrupt unmasked - IO-APIC's pin#7: IRR=0, interrupt unmasked (in fact mask/unmask_ioapic_irq have never been called by the IRQ follow controller handle_fasteoi_irq) So the touchpad has been generating interrupts most of the time while IO-APIC controller hasn't been masking the interrupt from the GPIO chip. But somehow the kernel could only get ~7 interrupts each second while the touchpad could generate 140 interrupts (time resolution of 7.2ms) per second. Assuming IO-APIC (arch/x86/kernel/apic/io_apic.c) is fine, then there's something wrong with the GPIO interrupt controller which works fine for the touchpad under Windows. Besides if I poll the touchpad data based on pin#130's status, the touchpad could also work under Windows. Ways to debug pinctrl-amd ========================= I can't find any documentation about the AMDI0030 GPIO chip except for the commit logs of drivers/pinctrl/pinctrl-amd. One commit ba714a9c1dea85e0bf2899d02dfeb9c70040427c ("pinctrl/amd: Use regular interrupt instead of chained") inspired me to bring back chained interrupt to see if "an interrupt storm" would happen. The only change I noticed is that the interrupts arrive in pairs. The time internal between two interrupts in a pair is ~0.0016s but the time internal between interrupt pairs is still ~0.12s (~8Hz). Unfortunately, I don't get any insight about the GPIO interrupt controller from this tweaking. I wonder if there are any other ways to debug drivers/pinctrl/pinctrl-amd? Thank you! [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190 -- Best regards, Coiby
-- Best regards, Coiby
