Hi,
at 05:18, <hotwater438@xxxxxxxxxxxx> <hotwater438@xxxxxxxxxxxx> wrote:
Hi.
1) Run "cat /proc/interrupts | grep ELAN" , note down the value
2) Very quickly/briefly touch the touchpad once
3) Run "cat /proc/interrupts | grep ELAN" , note down the value again
4) Subtract result from 1. from result from 3, this difference is
the value we are interested in. E.g. my testing got 254 and 257, so
a difference of 3.
I've tested that, main diffs are 30, 24, 16 (the most frequent), 2 (the
least frequent).
I was using 4.19.13 kernel, because I use ParrotOS (which happens to be
Debian distribution).
But I've installed experimental 5.0.0 kernel and I can't say right now if
suspend problem is resolved (i have to rebuild latest kernel with patch).
Can you try below fix?
This can solve what commit 1475af255e18 ("HID: i2c-hid: Ignore input report
if there's no data present on Elan touchpanels”) tries to workaround.
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
b/drivers/pinctrl/intel/pinctrl-intel.c
index c19a4c45f7bb..30e3664f1ae5 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -957,6 +957,10 @@ static void intel_gpio_irq_mask_unmask(struct irq_data
*d, bool mask)
reg = community->regs + community->ie_offset + gpp * 4;
raw_spin_lock_irqsave(&pctrl->lock, flags);
+
+ if (!mask)
+ writel(BIT(gpp_offset), community->regs +
community->is_offset + gpp * 4);
+
value = readl(reg);
if (mask)
value &= ~BIT(gpp_offset);
Regards,
Vladislav.
Apr 3, 2019, 2:18 PM by hdegoede@xxxxxxxxxx:
Hi,
On 31-03-19 11:50, hotwater438@xxxxxxxxxxxx wrote:
Hi. I've done everything you said, here are results:
Vladislav can you check the output of /cat/interrupts on a kernel
without the patch and while *not* using the touchpad; and check
if the amount of touchpads-interrupts still keeps increasing in this
case?
IWI or IRQ work interrupts keep increasing with speed at least 3
interrupts/s.
I'm really only interested in the touchpad related IRQs, so e.g. the line
about "intel-gpio 129 ELAN1200:00", if you're seeing 3 interrupts/s on
some others that is fine, so I take it the ELAN1200:00 interrupt count
does not increase on an *unpatched* kernel, unless you use the touchpad?
Also when I am moving touchpad IR-IO-APIC 14-fasteoi INT345D:00 get's
triggered and increased.
That is the GPIO controller interrupt, so that one increasing is normal.
If I understand things correctly then this all means that the IRQ indeed
is a normal level IRQ and Dmitry is likely correct that there is an
pinctrl / gpiochip driver problem here.
Can you try the following with an *unpatched* kernel? :
1) Run "cat /proc/interrupts | grep ELAN" , note down the value
2) Very quickly/briefly touch the touchpad once
3) Run "cat /proc/interrupts | grep ELAN" , note down the value again
4) Subtract result from 1. from result from 3, this difference is
the value we are interested in. E.g. my testing got 254 and 257, so
a difference of 3.
The goal here is to get an as low as possible difference. Feel free
to repeat this a couple of times.
On an Apollo Lake laptop with an I2C hid mt touchpad I can get the
amount of interrupts triggered for a single touch down to 3,
given the huge interrupt counts of 130000+ reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=1543769
I expect you to get a much bigger smallest possible difference
between 2 "cat /proc/interrupts | grep ELAN" commands, note a
difference of 0 means your touch did not register.
Assuming you indeed see much more interrupts for a very quick
touch + release, then we indeed have an interrupt handling problem
we need to investigate further.
I don't know if it's important or not, but for some reason these
interrupts keep popping only on CPU2 (i have 4cpu processor).
That does not matter.
1) Suspending the machine by selecting suspend from a menu in your
desktop environment, or by briefly pressing the power-button, do
not close the lid
2) As soon as the system starts suspending and while it is suspended, move
your finger around the touchpad
3) Wake the system up with the powerbutton while moving your finger around
4) Check if the touchpad still works after this
It works, but as it seems, looses edge. JournalCTL is being flooded with
i2c_hid_get_input: incomplete report (16/65535)
That is probably a different issue. If you loose the edge IRQ, then the
touchpad
would stop working without any messages. I believe that the suspend /
resume
issue may be fixed by:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=52cf93e63ee672a92f349edc6ddad86ec8808fd8
Does your kernel have this commit? (please always use the latest kernel
while
testing).
Also a thing to notice, that after manually removing and modprobing
i2c_hid module, it says next in journalctl:
i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not found, using
dummy regulator
i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vddl not found, using
dummy regulator
Those messages can safely be ignored.
Regards,
Hans
