On Mon, Oct 2, 2017 at 6:00 AM, Daniel Drake <drake@xxxxxxxxxxxx> wrote: > On Asus laptop models X505BA, X505BP, X542BA and X542BP, the i2c-hid > touchpad (using a GPIO for interrupts) becomes unresponsive after a > few minutes of usage, or after placing two fingers on the touchpad, > which seems to have the effect of queuing up a large amount of input > data to be transferred. > > When the touchpad is in unresponsive state, we observed that the GPIO > level-triggered interrupt is still at it's active level, however the > pinctrl-amd driver is not receiving/dispatching more interrupts at this > point. > > After the initial interrupt arrives, amd_gpio_irq_mask() is called > however we then see amd_gpio_irq_handler() being called repeatedly for > the same irq; the interrupt mask is not taking effect because of the > following sequence of events: > - amd_gpio_irq_handler fires, reads and caches pin reg > - amd_gpio_irq_handler calls generic_handle_irq() > - During IRQ handling, amd_gpio_irq_mask() is called and modifies pin reg > - amd_gpio_irq_handler clears interrupt by writing cached value > > The stale cached value written at the final stage undoes the masking. > Fix this by re-reading the register before clearing the interrupt. > > I also spotted that the interrupt-clearing code can race against > amd_gpio_irq_mask() / amd_gpio_irq_unmask(), so add locking there. > Presumably this race was leading to the loss of interrupts. > > After these changes, the touchpad appears to be working fine. > > Signed-off-by: Daniel Drake <drake@xxxxxxxxxxxx> Patch applied for fixes with Nehal-bakulchandra's ACK. Yours, Linus Walleij -- 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