Bug 198715 - Mis-configured ACPI config-table brakes Elan touchscreen on HP Envy x360 series running AMD processors
Summary: Mis-configured ACPI config-table brakes Elan touchscreen on HP Envy x360 seri...
Status: RESOLVED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Tables (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_input-devices
URL:
Keywords:
: 199529 (view as bug list)
Depends on: 199523 199529
Blocks: 201817
  Show dependency tree
 
Reported: 2018-02-07 20:50 UTC by Aidan Hahn
Modified: 2018-11-30 09:40 UTC (History)
43 users (show)

See Also:
Kernel Version: 4.18
Tree: Mainline
Regression: No


Attachments
dmesg output after boot (69.59 KB, text/plain)
2018-02-07 20:50 UTC, Aidan Hahn
Details
DMESG on 4.16rc1 (63.18 KB, text/plain)
2018-02-13 01:27 UTC, Aidan Hahn
Details
Disassembled ACPI table for HP Envy x360 15z (ryzen 5 2500u) (566.89 KB, text/x-csrc)
2018-02-13 03:11 UTC, Aidan Hahn
Details
DMESG output after boot on 4.16 (drm-next) (74.41 KB, text/plain)
2018-03-16 07:16 UTC, Aidan Hahn
Details
dmesg output from kernel 4.16(with hacks) (187.72 KB, text/plain)
2018-04-15 00:37 UTC, Lukas Kahnert
Details
possible fix for touchscreen (1.50 KB, patch)
2018-04-15 14:52 UTC, Lukas Kahnert
Details | Diff
config for working system (136.01 KB, text/x-mpsub)
2018-04-15 18:37 UTC, g.fitch
Details
"Fixing" the ACPI Error the other way around: patching the acpi table (1.23 KB, patch)
2018-04-30 10:40 UTC, Daniel Andersen
Details | Diff
DMESG with Lukas' patch and "irq 7: nobody cared" error (101.90 KB, text/plain)
2018-08-09 22:13 UTC, kk1987
Details
DMESG with Lukas' patch and "irqpoll" option (110.38 KB, text/plain)
2018-08-09 22:13 UTC, kk1987
Details
ACPI from the intel version of the Envy X360 15 (2018/2019 Model "15-CN) (1.33 MB, text/plain)
2018-08-09 22:50 UTC, Daniel Andersen
Details
turn on GSI on x86 platform (380 bytes, patch)
2018-09-01 16:40 UTC, crab2313
Details | Diff
Ryan 15m-cp0012dx F.19 Rev.A dmesg (64.33 KB, text/plain)
2018-09-05 20:56 UTC, Ryan Heath
Details
Ryan 15m-cp0012dx F.19 Rev.A dsdt.dat (84.98 KB, application/octet-stream)
2018-09-05 20:57 UTC, Ryan Heath
Details
attachment-20618-0.html (1.62 KB, text/html)
2018-10-30 06:20 UTC, Aidan Hahn
Details
Output of dmesg after booting kernel 4.19.2 with new patch (70.57 KB, text/plain)
2018-11-19 14:32 UTC, Marc
Details
[PATCH] ACPI / platform: Add SMB0001 HID to forbidden_id_list (872 bytes, patch)
2018-11-19 16:45 UTC, Hans de Goede
Details | Diff
Output of dmesg after booting kernel 4.19.2 with new patch v2 (touchscreen works) (71.37 KB, text/plain)
2018-11-19 17:06 UTC, Marc
Details

Description Aidan Hahn 2018-02-07 20:50:42 UTC
Created attachment 274057 [details]
dmesg output after boot

I have an HP Envy x360 with a ryzen 5 2500U processor and I am running kernel 4.15.0-staging. When I am running windows 10 my touchscreen does work, and is detected as a hid-compliant touchscreen. I was able to pull some driver information from windows event viewer. It looks like windows is using the following driver: HID\ELAN0732&Col01\4&2e44c06e&0&0000  .
I have been communicating with people at the wacom-hid-descriptors repository and was advised that this is a kernel issue.
It does seem like the kernel can see my devices at   
/sys/devices/platform/AMDI0010:00/i2c-0/i2c-ELAN0732:00  and
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/AMDI0010:00/ELAN0732:00 . 
however even after loading the hid-touchscreen module, the i2c-hid module, and the elants-i2c module my touchscreen is not working. 
I do have some ACPI errors in my dmesg log (attached) but I am not sure they are related. Let me know if there is additional information I can get you.
Comment 1 Jason Gerecke 2018-02-07 21:26:05 UTC
Link to the wacom-hid-descriptors bug report, for reference: https://github.com/linuxwacom/wacom-hid-descriptors/issues/12
Comment 2 g.fitch 2018-02-12 10:41:16 UTC
This appears to be related - same machine (HP Envy x360 with Ryzen):

[    7.650876] i2c_designware AMDI0010:00: ACPI slave is not supported yet
[    7.650913] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
[    7.650919] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
[    7.651103] i2c-dev: adapter [Synopsys DesignWare I2C adapter] registered as minor 5
[    7.651111] i2c i2c-5: adapter [Synopsys DesignWare I2C adapter] registered
[    7.651711] i2c i2c-5: client [ELAN0732:00] registered with bus id i2c-ELAN0732:00
[    7.677151] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
[    7.677157] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
Comment 3 Aidan Hahn 2018-02-13 01:25:31 UTC
I just tried kernel 4.16rc1
Touchscreen is still not operating. output very similar to 4.15 will attach another dmesg

(In reply to g.fitch from comment #2)
> This appears to be related - same machine (HP Envy x360 with Ryzen):
> 
> [    7.650876] i2c_designware AMDI0010:00: ACPI slave is not supported yet
> [    7.650913] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
> [    7.650919] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
> [    7.651103] i2c-dev: adapter [Synopsys DesignWare I2C adapter] registered
> as minor 5
> [    7.651111] i2c i2c-5: adapter [Synopsys DesignWare I2C adapter]
> registered
> [    7.651711] i2c i2c-5: client [ELAN0732:00] registered with bus id
> i2c-ELAN0732:00
> [    7.677151] i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
> [    7.677157] i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239

Which kernel are you using? I dont even get this output.
Comment 4 Aidan Hahn 2018-02-13 01:27:15 UTC
Created attachment 274145 [details]
DMESG on 4.16rc1
Comment 5 Aidan Hahn 2018-02-13 03:10:16 UTC
I believe this problem to be related to the thread located here:
https://www.spinics.net/lists/linux-input/msg50784.html

I will attach disassembled ACPI tables in case they prove to be useful.
Comment 6 Aidan Hahn 2018-02-13 03:11:14 UTC
Created attachment 274147 [details]
Disassembled ACPI table for HP Envy x360 15z (ryzen 5 2500u)
Comment 7 g.fitch 2018-02-13 07:18:43 UTC
(In reply to Aidan Hahn from comment #3)

> Which kernel are you using? I dont even get this output.

4.15-drm-next (fixes a nasty problem with 3 out of 5 boots locking up - still get irritating lock-ups when using X, and especially anything opengl). 

I turned on i2c debugging to see the status messages that the i2c-hid, elants_i2c etc. modules should be printing if they find the device but have some other communications problem. 

I'm new to this, so not sure what I'm looking at, but I think the touchscreen only identifies itself through ACPI, as an i2c slave at its own address, and drivers/i2c/i2c-core-slave.c can't enumerate that yet. So the device node doesn't get created, and the hid drivers have nothing to connect to.

I could be completely wrong, though - I'm good at being wrong :)
Comment 8 Aidan Hahn 2018-02-13 20:45:06 UTC
(In reply to g.fitch from comment #7)
> (In reply to Aidan Hahn from comment #3)
> 
> > Which kernel are you using? I dont even get this output.
> 
> 4.15-drm-next (fixes a nasty problem with 3 out of 5 boots locking up -
> still get irritating lock-ups when using X, and especially anything opengl). 
> 
> I turned on i2c debugging to see the status messages that the i2c-hid,
> elants_i2c etc. modules should be printing if they find the device but have
> some other communications problem. 
> 
> I'm new to this, so not sure what I'm looking at, but I think the
> touchscreen only identifies itself through ACPI, as an i2c slave at its own
> address, and drivers/i2c/i2c-core-slave.c can't enumerate that yet. So the
> device node doesn't get created, and the hid drivers have nothing to connect
> to.
> 
> I could be completely wrong, though - I'm good at being wrong :)

What model number are you running? I am using a 15-bq100.
Comment 9 Aidan Hahn 2018-03-01 04:17:38 UTC
Not sure what more information I should provide,
If there is more information needed to troubleshoot this issue please let me know.
Comment 10 Aidan Hahn 2018-03-16 07:15:27 UTC
Updated kernel to 4.16 (drm-next) and upon compile turned on some i2c debugging features. Now when I boot I recieve the following:

[    0.187816] i2c i2c-0: client [ELAN0732:00] registered with bus id i2c-ELAN0732:00
[    1.301023] acpi ELAN0732:00: GPIO: looking up 0 in _CRS

(the second entry is repeated ad nauseum)

libwacom-list-local-devices still cannot see this device.
I have attached my new DMESG which still has the ACPI Errors, among some additional interesting output from the i2c subsystem.

Am I missing something? Have I sent this bug to the right place?
Comment 11 Aidan Hahn 2018-03-16 07:16:09 UTC
Created attachment 274773 [details]
DMESG output after boot on 4.16 (drm-next)
Comment 12 Lukas Kahnert 2018-04-15 00:33:33 UTC
I recently bought the same laptop and tried to look deeper into the problem.
I'm not a kernel developer or have any knowledge in kernel subsystems but what I found so far is that the AMD GPIO driver doesn't support ACPI for x86 platforms.(Kernel 4.16)
On HP Envy x360(Ryzen) the GPIO device is detected as ACPI device with an interrupt resource.

The driver calls for this case the function acpi_get_irq which is only defined on ARM64. On other platforms it returns a hardcoded -EIVAL (error -22).
I tried to hack a workround and used acpi_dev_resource_interrupt to get the IRQ from ACPI. The driver prints some warnings but the probe was successful.
The next problem is the i2c device itself.
The i2c-hid module fails to reset the device(error -61).
As dirty hack I deleted the timeout error, just to create a hidraw device by hid-multitouch but it doesn't report any input(it's detected as HID Input device).

It's possible:
- That there is still something missing in the AMD GPIO driver(especially at the gpio interrupts)
- My hack with the ACPI IRQ is completly crap
- The i2c device needs some magic bits or something to start working
I saw threads and bug reports in the internet with this touchscreen device but there was never a solution for the -61 error.

Of course there are more posibilities but that are the things I found out so far.
Pls tell me if some more info or debug is required.
Comment 13 Lukas Kahnert 2018-04-15 00:37:33 UTC
Created attachment 275377 [details]
dmesg output from kernel 4.16(with hacks)

dmesg output from kernel with hacks included (the beginning is missing, maybe a limit of busybox but the relevant output is visible)
Comment 14 Lukas Kahnert 2018-04-15 14:52:21 UTC
Created attachment 275381 [details]
possible fix for touchscreen

I think I found the problem.
There are 2 ACPI-related bugs which prevents the detection of the touchscreen.

1. As already mentioned, the AMD GPIO driver tries to get an IRQ for GPIO but the ACPI code is missing for x86.
2. The IRQ of the GPIO device is misconfigured. For some reason it sets the IRQ "edge, high" but in the ACPI table it's defined as "level, low".

I made a fix but it's only a temporary workround until someone who have more knowledge of the subsystems can implement it cleaner.
Could someone try this patch on a desktop enviroment? I just tested the output of hidraw which worked.
Comment 15 g.fitch 2018-04-15 17:12:09 UTC
Hi Lukas,

I tested it with KDE 5 (17.12.3) with one of the drm-next kernels:
Linux tau-ceti 4.16.0-rc7-gc5902206599d-dirty #4 SMP PREEMPT Sun Apr 15 17:37:13 BST 2018 x86_64 AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx AuthenticAMD GNU/Linux


Your patch works fine for the touchscreen on this laptop - touchscreen is detectable and usable with both finger and the supplied pen.  

The relevant bit of dmesg is:

Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: ACPI slave is not supported yet
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Standard-mode HCNT:LCNT = 642:749
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Fast-mode HCNT:LCNT = 132:239
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: GPIO lookup for consumer scl
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using ACPI for GPIO lookup
Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpios
Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpio
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using lookup tables for GPIO lookup
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: lookup for GPIO scl failed
Apr 15 17:47:11 tau-ceti kernel: i2c-dev: adapter [Synopsys DesignWare I2C adapter] registered as minor 5
Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: adapter [Synopsys DesignWare I2C adapter] registered
Apr 15 17:47:11 tau-ceti kernel: acpi ELAN0732:00: GPIO: looking up 0 in _CRS
Apr 15 17:47:11 tau-ceti kernel: gpio gpiochip0: Persistence not supported for GPIO 89
Apr 15 17:47:11 tau-ceti kernel: i2c_hid i2c-ELAN0732:00: probe
Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[0] W, addr=0x10, len=2
Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[1] R, addr=0x10, len=30
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: i2c_dw_xfer: msgs: 2
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1 stat=0x10
Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1 stat=0x504
Apr 15 17:47:11 tau-ceti last message repeated 9 times



The patch creates one issue, which is that the following warning now pops up at boot:

The battery in your keyboard ("ELAN0732:00 04F3:2537") is low, and the device may turn itself off at any time. Please replace or charge the battery as soon as possible. 

However all other peripherals and buttons work fine, so it's a minor nuisance.

Thank you for getting us this far!
Comment 16 g.fitch 2018-04-15 18:37:53 UTC
Created attachment 275385 [details]
config for working system

4.16.0-rc7-gc5902206599d built against sources from git://people.freedesktop.org/~agd5f/linux --branch drm-next-4.18-wip
Comment 17 Lukas Kahnert 2018-04-15 19:03:18 UTC
(In reply to g.fitch from comment #15)
> Hi Lukas,
> 
> I tested it with KDE 5 (17.12.3) with one of the drm-next kernels:
> Linux tau-ceti 4.16.0-rc7-gc5902206599d-dirty #4 SMP PREEMPT Sun Apr 15
> 17:37:13 BST 2018 x86_64 AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx
> AuthenticAMD GNU/Linux
> 
> 
> Your patch works fine for the touchscreen on this laptop - touchscreen is
> detectable and usable with both finger and the supplied pen.  
> 
> The relevant bit of dmesg is:
> 
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: ACPI slave is
> not supported yet
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Standard-mode
> HCNT:LCNT = 642:749
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: Fast-mode
> HCNT:LCNT = 132:239
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: GPIO lookup for
> consumer scl
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using ACPI for
> GPIO lookup
> Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpios
> Apr 15 17:47:11 tau-ceti kernel: acpi AMDI0010:00: GPIO: looking up scl-gpio
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: using lookup
> tables for GPIO lookup
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: lookup for GPIO
> scl failed
> Apr 15 17:47:11 tau-ceti kernel: i2c-dev: adapter [Synopsys DesignWare I2C
> adapter] registered as minor 5
> Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: adapter [Synopsys DesignWare I2C
> adapter] registered
> Apr 15 17:47:11 tau-ceti kernel: acpi ELAN0732:00: GPIO: looking up 0 in _CRS
> Apr 15 17:47:11 tau-ceti kernel: gpio gpiochip0: Persistence not supported
> for GPIO 89
> Apr 15 17:47:11 tau-ceti kernel: i2c_hid i2c-ELAN0732:00: probe
> Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[0] W, addr=0x10,
> len=2
> Apr 15 17:47:11 tau-ceti kernel: i2c i2c-5: master_xfer[1] R, addr=0x10,
> len=30
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: i2c_dw_xfer:
> msgs: 2
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1
> stat=0x10
> Apr 15 17:47:11 tau-ceti kernel: i2c_designware AMDI0010:00: enabled=0x1
> stat=0x504
> Apr 15 17:47:11 tau-ceti last message repeated 9 times
> 
> 
> 
> The patch creates one issue, which is that the following warning now pops up
> at boot:
> 
> The battery in your keyboard ("ELAN0732:00 04F3:2537") is low, and the
> device may turn itself off at any time. Please replace or charge the battery
> as soon as possible. 
> 
> However all other peripherals and buttons work fine, so it's a minor
> nuisance.
> 
> Thank you for getting us this far!

It looks like upower/i2c-hid think the touchscreen has a battery (which is false) and reports a invalid power value of 0. When I get a working desktop I could take a look for it. Meanwhile switching CONFIG_HID_BATTERY_STRENGTH off should silence the warning if you don't rely on this feature.
Comment 18 Bráulio Bhavamitra 2018-04-25 22:24:08 UTC
(In reply to Lukas Kahnert from comment #14)
> Created attachment 275381 [details]
> possible fix for touchscreen
> 
> I think I found the problem.
> There are 2 ACPI-related bugs which prevents the detection of the
> touchscreen.
> 
> 1. As already mentioned, the AMD GPIO driver tries to get an IRQ for GPIO
> but the ACPI code is missing for x86.
> 2. The IRQ of the GPIO device is misconfigured. For some reason it sets the
> IRQ "edge, high" but in the ACPI table it's defined as "level, low".
> 
> I made a fix but it's only a temporary workround until someone who have more
> knowledge of the subsystems can implement it cleaner.
> Could someone try this patch on a desktop enviroment? I just tested the
> output of hidraw which worked.

Thanks Lukas, this makes it work!!!

BTW, are you getting hangs/freezes possibly related to the amdgpu driver?
Comment 19 Bráulio Bhavamitra 2018-04-25 22:25:44 UTC
Also Lukas, can you upstream this patch?
Comment 20 Lukas Kahnert 2018-04-26 15:30:47 UTC
@Bráulio I'm sorry but I'm not a kernel developer and this patch is just a dirty hack, which only works on this notebook. On other hardware it could make the system unbootable.
For upstream it needs a cleaner solution.

I already made a bugreport for the IRQ issue:
https://bugzilla.kernel.org/show_bug.cgi?id=199523

For the bug in the AMD GPIO driver it's a missing ACPI feature(I think). My patch comments out this snippet which triggers the error but I'm absolutely unsure if it represents a correct behaviour for (all)x86/amd64 systems. As long the touchscreen and the other hardware works ok, it should be safe for the notebook.
Comment 21 Daniel Andersen 2018-04-30 10:30:40 UTC
Well, there is another temporary solution and that is fixing the ACPI table. 

I have seen this error for quite a long time, as the A10/A12 Envy X360 Notebooks made in 2016/2017 also have the same error. 

Based on the Howto of https://wiki.archlinux.org/index.php/DSDT 
you can extract the ACPI table, then increase the version (This number may be different on your installed firmware) number of the first row: 
-DefinitionBlock ("", "DSDT", 2, "HPQOEM", "83C6    ", 0x01072009)
+DefinitionBlock ("", "DSDT", 2, "HPQOEM", "83C6    ", 0x01072010)

and change the AMDGPIO part:
@@ -4447,7 +4447,7 @@
             {
                 Name (RBUF, ResourceTemplate ()
                 {
-                    Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
+                    Interrupt (ResourceConsumer, Edge, ActiveHigh, Shared, ,, )
                     {
                         0x00000007,
                     }



If you inject that modified and recompiled ACPI, the same fix should work for any kernel which supports the ELAN touch controller. 

If that can be double checked by the owners, it would be a chance to push this work back to HP to fix their ACPI table.
Comment 22 Daniel Andersen 2018-04-30 10:40:04 UTC
Created attachment 275675 [details]
"Fixing" the ACPI Error the other way around: patching the acpi table

Instead of adding a temporary hack into the kernel, it is also possible to patch the acpi table which is created by the HP Firmware. This should work with all kernels and this would show that the main work to do is on HPs side - not on the kernel developers side.
Comment 23 m.kolesinski 2018-05-02 14:06:31 UTC
(In reply to Daniel Andersen from comment #22)
> Created attachment 275675 [details]
> "Fixing" the ACPI Error the other way around: patching the acpi table
> 
> Instead of adding a temporary hack into the kernel, it is also possible to
> patch the acpi table which is created by the HP Firmware. This should work
> with all kernels and this would show that the main work to do is on HPs side
> - not on the kernel developers side.

I can confirm that hand-patching the ACPI to change the GPIO interrupt type/level eliminates the same GPIO error on my HP M6AR004DX laptop, which has an FX-9800P.  The ELAN0732 touchscreen still isn't working (on to the next error)...with the patched ACPI:

[    8.464309] i2c_hid i2c-ELAN0732:00: i2c-ELAN0732:00 supply vdd not found, using dummy regulator
[   13.490200] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   19.676718] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   25.863360] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   32.050080] i2c_hid i2c-ELAN0732:00: failed to reset device.
[   33.063523] i2c_hid i2c-ELAN0732:00: can't add hid device: -61
[   33.063732] i2c_hid: probe of i2c-ELAN0732:00 failed with error -61

I've been trying to find information on how to fix this darned touchscreen controller for about a year.  The comments in this thread are the first that have actually made any real progress forward, so thank you to those that were able to dig into this.
Comment 24 David Pedersen 2018-05-02 23:25:17 UTC
(In reply to m.kolesinski from comment #23)
> (In reply to Daniel Andersen from comment #22)
> > Created attachment 275675 [details]
> > "Fixing" the ACPI Error the other way around: patching the acpi table
> > 
> > Instead of adding a temporary hack into the kernel, it is also possible to
> > patch the acpi table which is created by the HP Firmware. This should work
> > with all kernels and this would show that the main work to do is on HPs
> side
> > - not on the kernel developers side.
> 
> I can confirm that hand-patching the ACPI to change the GPIO interrupt
> type/level eliminates the same GPIO error on my HP M6AR004DX laptop, which
> has an FX-9800P.  The ELAN0732 touchscreen still isn't working (on to the
> next error)...with the patched ACPI:
> 
> [    8.464309] i2c_hid i2c-ELAN0732:00: i2c-ELAN0732:00 supply vdd not
> found, using dummy regulator
> [   13.490200] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   19.676718] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   25.863360] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   32.050080] i2c_hid i2c-ELAN0732:00: failed to reset device.
> [   33.063523] i2c_hid i2c-ELAN0732:00: can't add hid device: -61
> [   33.063732] i2c_hid: probe of i2c-ELAN0732:00 failed with error -61
> 
> I've been trying to find information on how to fix this darned touchscreen
> controller for about a year.  The comments in this thread are the first that
> have actually made any real progress forward, so thank you to those that
> were able to dig into this.

Hear hear! Glad to see some progress on this! I've been trying to resolve the touchscreen issue since my purchase of the Envy x360 a few weeks ago. Kudos to those of you working on it. I'll be monitoring and look forward to a solution.
Comment 25 Marc 2018-05-07 07:20:35 UTC
Lukas' patch works for me.

The touchscreen works with a patched Linux 4.17-rc3 on a HP ENVY x360 15-bq102ng with Ubuntu 18.04 :) Thank you so much!

Modifying the ACPI table gives me the same result that m.kolesinski@gmail.com described.

I hope there there will be some generic solution that can be mainlined.
Comment 26 David Pedersen 2018-05-11 01:34:46 UTC
Lukas' patch also worked for me. Ubuntu 18.04 patched to Linux kernel 4.17-rc4 on my HP Envy x360 15-bq100 Convertible. Thanks to all that contributed to this issue!
Comment 27 Nicola Sorace 2018-05-13 02:02:15 UTC
Hello!

I think I managed to apply Daniel's ACPI table patch, but the touchscreen still doesn't work. I now get this error in dmesg:

[    2.284918] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided an Int IRQ
[    2.286070] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22

I don't really know what I'm doing (took me like two days to apply the patch) so I'm sorry if I've done something dumb. I reaaally want to get this touchscreen working.
Comment 28 Marc 2018-05-13 06:58:58 UTC
(In reply to Nicola Sorace from comment #27)
> Hello!
> 
> I think I managed to apply Daniel's ACPI table patch, but the touchscreen
> still doesn't work. I now get this error in dmesg:
> 
> [    2.284918] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided
> an Int IRQ
> [    2.286070] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22
> 
> I don't really know what I'm doing (took me like two days to apply the
> patch) so I'm sorry if I've done something dumb. I reaaally want to get this
> touchscreen working.

The ACPI variant still does not work at the moment. 
If you are using Ubuntu I can share the kernel image that I built with you.
Comment 29 Nicola Sorace 2018-05-13 12:32:33 UTC
(In reply to Marc from comment #28)
> (In reply to Nicola Sorace from comment #27)
> > Hello!
> > 
> > I think I managed to apply Daniel's ACPI table patch, but the touchscreen
> > still doesn't work. I now get this error in dmesg:
> > 
> > [    2.284918] i2c_hid i2c-ELAN0732:00: HID over i2c has not been provided
> > an Int IRQ
> > [    2.286070] i2c_hid: probe of i2c-ELAN0732:00 failed with error -22
> > 
> > I don't really know what I'm doing (took me like two days to apply the
> > patch) so I'm sorry if I've done something dumb. I reaaally want to get
> this
> > touchscreen working.
> 
> The ACPI variant still does not work at the moment. 
> If you are using Ubuntu I can share the kernel image that I built with you.

I'm running Arch unfortunately. Will I have to recompile the kernel with Lukas' patch applied or is there another way?
Comment 30 Marc 2018-05-14 06:36:08 UTC
(In reply to Nicola Sorace from comment #29)
> I'm running Arch unfortunately. Will I have to recompile the kernel with
> Lukas' patch applied or is there another way?

As far as I know, there is no other way, currently.
Comment 31 Nicola Sorace 2018-05-15 18:40:48 UTC
Lukas' patch worked! Touchscreen worked immediately after booting into new kernel. Thank you all so much!
Comment 32 ryanmcg 2018-06-17 14:40:17 UTC
Hoping to keep discussion of this issue alive. I can also confirm that the patch works, though I found it very difficult to implement as someone who has not done any kernel patching before. And since I am trying to keep up with kernel updates in the hopes of solving various other issues, this needs to be done repeatedly. Any hope of a permanent solution?

I also made a question at AskUbuntu to discuss the other various issues with this laptop:
https://askubuntu.com/questions/1047374/hp-envy-x360-ryzen-5-status-of-known-issues
Comment 33 Ian Tompkins 2018-06-23 04:08:51 UTC
Is it possible for anyone to link to a compiled version of the kernel with the fix installed? I am having a heck of a time figuring out how to get it decompiled and the new code inserted.


Thanks ahead of time.
Comment 34 Robert Munn 2018-06-30 05:16:04 UTC
(In reply to ryanmcg from comment #32)
> Any hope of a permanent solution?

Someone will need to write a more permanent solution than Lukas' hack and get it mainlined. Any HP or AMD kernel devs on this bug report? :-)
Comment 35 kk1987 2018-08-09 22:09:18 UTC
I tried Lukas' patch on both the latest gen x360 15z and 13z (model is 13z-ag000), and while it sometimes work perfectly, on some boots I get a "irq 7: nobody cared (try booting with the "irqpoll" option)" line followed by a "Disabling IRQ #7" message in dmesg, and the touchscreen stops working.

Booting with "irqpoll" does ensure a working touchscreen, but it seems to have a negative impact on battery life due to there being 8-9k IRQs per second constantly. Also, some new warning messages appeared in dmesg once irqpoll is enabled: a "hpet1: lost 9601 rtc interrupts" message repeats every 1-2 seconds ("hpet=disable" removes this, but doesn't help with the high number of IRQs per second), and a "i2c_hid i2c-ELAN0732:00: i2c_hid_get_input: incomplete report (67/65535)" warning happens with every touchscreen event.

I have a dual-boot setup with Windows 10, and the issue seems to be somehow affected by the other OS - rebooting from Windows 10 seems to guarantee a non-working touchscreen; however, cold booting directly into Linux (I tried Fedora 28 & Fedora Rawhide) does not guarantee a working touchscreen.

Did anyone experience the same problem? Or have ideas what the root cause or any workarounds might be?
Comment 36 kk1987 2018-08-09 22:13:05 UTC
Created attachment 277793 [details]
DMESG with Lukas' patch and "irq 7: nobody cared" error
Comment 37 kk1987 2018-08-09 22:13:37 UTC
Created attachment 277795 [details]
DMESG with Lukas' patch and "irqpoll" option
Comment 38 Daniel Andersen 2018-08-09 22:50:45 UTC
Created attachment 277797 [details]
ACPI from the intel version of the Envy X360 15 (2018/2019 Model "15-CN)

Hi, 

Just for comparison the ACPI Table of the 2018/2019 Model of the HP Envy X360 15-CN0000 ( Intel 8th Gen CPU ). The ELAN config looks a bit more sophisticated. 

Amd 15-BQ Model:    Device (TPNL)
Intel 15-CN Model:  Device (TPL1)
Comment 39 Lukas Kahnert 2018-08-10 15:35:08 UTC
(In reply to kk1987 from comment #35)
> I tried Lukas' patch on both the latest gen x360 15z and 13z (model is
> 13z-ag000), and while it sometimes work perfectly, on some boots I get a
> "irq 7: nobody cared (try booting with the "irqpoll" option)" line followed
> by a "Disabling IRQ #7" message in dmesg, and the touchscreen stops working.
> 
> Booting with "irqpoll" does ensure a working touchscreen, but it seems to
> have a negative impact on battery life due to there being 8-9k IRQs per
> second constantly. Also, some new warning messages appeared in dmesg once
> irqpoll is enabled: a "hpet1: lost 9601 rtc interrupts" message repeats
> every 1-2 seconds ("hpet=disable" removes this, but doesn't help with the
> high number of IRQs per second), and a "i2c_hid i2c-ELAN0732:00:
> i2c_hid_get_input: incomplete report (67/65535)" warning happens with every
> touchscreen event.
> 
> I have a dual-boot setup with Windows 10, and the issue seems to be somehow
> affected by the other OS - rebooting from Windows 10 seems to guarantee a
> non-working touchscreen; however, cold booting directly into Linux (I tried
> Fedora 28 & Fedora Rawhide) does not guarantee a working touchscreen.
> 
> Did anyone experience the same problem? Or have ideas what the root cause or
> any workarounds might be?

this behaviour occurs on my laptop when I reboot from windows. I need to complete power off/cold boot to workround the irq-issue. Sometimes the touchpad don't even get detected when I booted windows before. I think Linux lacks of some reset features for the ACPI IRQs on HP Envy x360.

I'm sorry but I'm too busy for debug the issue. I still hope a kernel developer comes and creates a real fix :)
Comment 40 Bram Coenen 2018-08-11 06:43:56 UTC
Hej!

I'm new to how bug reporting works in Linux and have the same problem. (Hence me being here) How do we get the attention of a kernel developer? How can we find who to ask? Is there someone like a "package maintainer" for this?
Comment 41 kk1987 2018-08-11 17:12:54 UTC
(In reply to Lukas Kahnert from comment #39)
> (In reply to kk1987 from comment #35)
> > I tried Lukas' patch on both the latest gen x360 15z and 13z (model is
> > 13z-ag000), and while it sometimes work perfectly, on some boots I get a
> > "irq 7: nobody cared (try booting with the "irqpoll" option)" line followed
> > by a "Disabling IRQ #7" message in dmesg, and the touchscreen stops
> working.
> > 
> > Booting with "irqpoll" does ensure a working touchscreen, but it seems to
> > have a negative impact on battery life due to there being 8-9k IRQs per
> > second constantly. Also, some new warning messages appeared in dmesg once
> > irqpoll is enabled: a "hpet1: lost 9601 rtc interrupts" message repeats
> > every 1-2 seconds ("hpet=disable" removes this, but doesn't help with the
> > high number of IRQs per second), and a "i2c_hid i2c-ELAN0732:00:
> > i2c_hid_get_input: incomplete report (67/65535)" warning happens with every
> > touchscreen event.
> > 
> > I have a dual-boot setup with Windows 10, and the issue seems to be somehow
> > affected by the other OS - rebooting from Windows 10 seems to guarantee a
> > non-working touchscreen; however, cold booting directly into Linux (I tried
> > Fedora 28 & Fedora Rawhide) does not guarantee a working touchscreen.
> > 
> > Did anyone experience the same problem? Or have ideas what the root cause
> or
> > any workarounds might be?
> 
> this behaviour occurs on my laptop when I reboot from windows. I need to
> complete power off/cold boot to workround the irq-issue. Sometimes the
> touchpad don't even get detected when I booted windows before. I think Linux
> lacks of some reset features for the ACPI IRQs on HP Envy x360.
> 
> I'm sorry but I'm too busy for debug the issue. I still hope a kernel
> developer comes and creates a real fix :)

Hey thanks for the reply and for writing the patch.

In case anyone had the same question, I realized why cold booting didn't always work for me: it looks like the power cord must be unplugged at least once when the laptop is powered off. I'm using a USB type-C power adapter and haven't tried the original adapter, but I suspect it's the same.
Comment 42 Jason Gerecke 2018-08-14 15:08:56 UTC
(In reply to Bram Coenen from comment #40)
> Hej!
> 
> I'm new to how bug reporting works in Linux and have the same problem.
> (Hence me being here) How do we get the attention of a kernel developer? How
> can we find who to ask? Is there someone like a "package maintainer" for
> this?

Just a quick drive-by comment... The kernel has a "MAINTAINERS" file (see https://www.kernel.org/doc/linux/MAINTAINERS) which lists the people who maintain its various subsystems. Mika Westerberg might be a good person to check with since he maintains the I2C ACPI bits.
Comment 43 Samuel Grahn 2018-08-22 09:41:46 UTC
Does Lukas' patch work? with newer kernels?

How would I apply it? Does anyone have a precompiled version (or a pkgbuild) for arch? Or Ubuntu?
Comment 44 crab2313 2018-09-01 16:40:49 UTC
Created attachment 278229 [details]
turn on GSI on x86 platform

    Can someone test this patch. I think the developer keep the config disabled on x86 because the code is not well tested and may break the kernel on some buggy firmware. https://patchwork.kernel.org/patch/9474763/
Comment 45 Maxime 2018-09-02 19:37:12 UTC
drivers/acpi/irq.o: In function `acpi_gsi_to_irq':
irq.c:(.text+0x0): multiple definition of `acpi_gsi_to_irq'
arch/x86/kernel/acpi/boot.o:boot.c:(.text+0x1a0): first defined here
drivers/acpi/irq.o: In function `acpi_register_gsi':
irq.c:(.text+0x70): multiple definition of `acpi_register_gsi'
arch/x86/kernel/acpi/boot.o:boot.c:(.text+0x0): first defined here
drivers/acpi/irq.o: In function `acpi_unregister_gsi':
irq.c:(.text+0xf0): multiple definition of `acpi_unregister_gsi'
arch/x86/kernel/acpi/boot.o:boot.c:(.text+0x10): first defined here
drivers/acpi/irq.o:(.bss+0x0): multiple definition of `acpi_irq_model'
arch/x86/kernel/acpi/boot.o:(.bss+0x8): first defined here
make: *** [Makefile:1010: vmlinux] Error 1

After applying the patch I get the above on 4.18.5
Comment 46 Sean 2018-09-03 03:31:59 UTC
I apologize if this is the wrong place to post this, but I've following this thread for a while and it could be related.

I bios update was released on the 29th of August for Ryzen HP Envy x360 13.3 inch version. (I assume it's also Ryzen, though) In the notes it says it fixes some issues with the touchscreen so I thought it might help.

Now, I can't even install any flavour of linux (I've tried Ubuntu 18.04.1 and the latest version of Pop!_OS) because as soon as I choose to boot from the install USB, it'll come up with the scrolling debug text and then go to a blackscreen where I can do nothing. I assume it's trying to access specific screen drivers and failing as the fans are still intermittently speeding up suggesting it's going through the usual process in the background.

Is there any way to troubleshoot this to find some specific errors?

Apologies if this is unrelated to the current issue at hand and deserves it's own bug report.
Comment 47 Sean 2018-09-03 04:31:12 UTC
To be specific, the BIOS update that caused the issue was 'F.19 Rev.A'

It's patch notes list this fix: "Fixes an issue which causes the touch screen to stop functioning properly'

I'll try and rollback to an earlier BIOS to see if this was my specific issue.
Comment 48 Thomas 2018-09-03 18:10:03 UTC
@crab
I've added  CONFIG_ACPI_GENERIC_GSI=y
to the config and just patched the low/high issue (without the patch of platform.c) and the touchscreen now works. 
In theory it now should work with the acpi table modification and compiling with CONFIG_ACPI_GENERIC_GSI=y too.
Comment 49 Maxime 2018-09-03 20:50:03 UTC
@Thomas
could you link the patch(es) you applied?
Comment 50 Thomas 2018-09-03 22:49:12 UTC
@Maxime 
I've basically used Lukas' patch , but removed the upper part of it (the one modifying platform.c).

Patching the acpi table as described above does not work. The problem seems to be that the values from the table are overwritten somehow, so patching it seems useless?

Then I added the CONFIG_ACPI_GENERIC_GSI=y to the "config" file of the Arch Linux source (https://git.archlinux.org/svntogit/packages.git/tree/trunk/config?h=packages/linux). I don't think that this file should be modified, since its header comment says so. I think the clean way would be crab2313s way, however this fails with the errors from above.
Comment 51 Steffen 2018-09-04 07:38:21 UTC
@Sean This bug is not related to this report. But I can help you as I run into the same problem with the same laptop. The bios update cannot be reset. I tried and failed. The only way to get this working again is to use the new Kernel 4.19 which is due for release in october. However you can boot your linux with the command nomodeset instead of quiet splash in your grub config (depends on your distro). After you boot linux, you can install the RC-Version of Kernel 4.19. I use openSUSE Tumbleweed and they have a certain repo for new Kernels.
Comment 52 Ryan Heath 2018-09-05 04:30:23 UTC
I was using Lukas' patch successfully until I also updated my BIOS hoping the "Fixes an issue which causes the touch screen to stop functioning properly" would fix having to patch the kernel. Now that I'm on 4.19-rc2 I applied the patch as I had been and the touchscreen isn't working again, I'm assuming they changed something in the new BIOS that also breaks that workaround?
Comment 53 Thomas 2018-09-05 05:56:47 UTC
@Ryan, which device? I still can't find a newer bios than the F.17 for my 15-bq101ng . 
Would you please provide your dmesg and dsdt?
Comment 54 Ryan Heath 2018-09-05 20:56:02 UTC
Created attachment 278325 [details]
Ryan 15m-cp0012dx F.19 Rev.A dmesg

I am using an Envy x360 15m-cp0012dx. The bios is version F.19 Rev.A https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-envy-15m-cp0000-x360-convertible-pc/20270308/model/21925604/swItemId/ob-217449-1

I'm new to this site so I hope this is the right way to comment and leave the attached files
Comment 55 Ryan Heath 2018-09-05 20:57:12 UTC
Created attachment 278327 [details]
Ryan 15m-cp0012dx F.19 Rev.A dsdt.dat

Followed the instructions on the arch wiki to create this dsdt. let me know if that's the wrong file.
Comment 56 Marco Azz 2018-10-15 16:04:56 UTC
Hi! I've been following a bit this discussion: it seems that those patches work, right?
Now, I've also noticed I'm not the only person who is a total noob with linux kernels and their compiling. What I would like to ask is if anyone can make a few steps guide on how to apply the patch and recompile the kernel (and how to install it since I don't think the output would be a standard .deb package, isn't it?).
Thanks a lot in advance!
Comment 57 Ryan Heath 2018-10-15 16:19:02 UTC
I'm not too familiar with Ubuntu but https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel would be a good place to start.
In a more general sense you need to get the kernel source, build it while applying the patch, install it in your boot directory, and update your boot loader to point at the new image.

https://askubuntu.com/questions/724900/how-to-apply-kernel-patches/724909#724909 Here is an example of how to patch the kernel in more detail on Ubuntu.
Comment 58 Dan Ankers 2018-10-23 22:58:21 UTC
I'm using a 13-ag0502sa.

When I was running BIOS version F.17 the touchscreen wouldn't work with any of these patches.  I've upgraded to BIOS F.20 and the touchscreen works with Lukas' patch, but not with a modified DSDT and an unpatched kernel.
Comment 59 Luya Tshimbalanga 2018-10-30 06:15:03 UTC
After reading the report, I suggest the original reporter to assign to ACPI Component-table component bug because it is clearly an ACPI error preventing the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen series.
I am adding one of ACPI maintainer on the list to check out.
Comment 60 Aidan Hahn 2018-10-30 06:20:29 UTC
Created attachment 279245 [details]
attachment-20618-0.html

Would you please clarify which component you are suggesting I add this to?
I do not see one labelled "table"

On Mon, Oct 29, 2018 at 11:15 PM <bugzilla-daemon@bugzilla.kernel.org>
wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=198715
>
> Luya Tshimbalanga (luya@fedoraproject.org) changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |lv.zheng@intel.com
>
> --- Comment #59 from Luya Tshimbalanga (luya@fedoraproject.org) ---
> After reading the report, I suggest the original reporter to assign to ACPI
> Component-table component bug because it is clearly an ACPI error
> preventing
> the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen
> series.
> I am adding one of ACPI maintainer on the list to check out.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.
Comment 61 Aidan Hahn 2018-10-30 06:21:16 UTC
My bad, I have assigned this bug properly.

Thank you!
Comment 62 m.kolesinski 2018-10-30 15:59:52 UTC
(In reply to Luya Tshimbalanga from comment #59)
> After reading the report, I suggest the original reporter to assign to ACPI
> Component-table component bug because it is clearly an ACPI error preventing
> the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen
> series.
> I am adding one of ACPI maintainer on the list to check out.

I want to be clear, this bug does not just affect Ryzen series CPUs/APUs, it also affects the previous gen CPUs, including the FX9800P in my x360, model m6-ar004dx.  It looks like they share the same GPIO config with respect to the i2c ELAN0734 touchscreen controller.

I would like to make sure whatever fix gets put in fixes all affected platforms, not just Ryzen.  I will gladly test driver/kernel patches and/or ACPI/DSDT patches.  I can also post my DSDT if it helps, it was very similar with regard to this GPIO to the one already discussed.

I have two identical laptops I can test with.
Comment 63 m.kolesinski 2018-10-30 16:00:23 UTC
(In reply to Luya Tshimbalanga from comment #59)
> After reading the report, I suggest the original reporter to assign to ACPI
> Component-table component bug because it is clearly an ACPI error preventing
> the touchscreen and by extent stylus that comes with HP Envy x360 Ryzen
> series.
> I am adding one of ACPI maintainer on the list to check out.

I want to be clear, this bug does not just affect Ryzen series CPUs/APUs, it also affects the previous gen CPUs, including the FX9800P in my x360, model m6-ar004dx.  It looks like they share the same GPIO config with respect to the i2c ELAN0734 touchscreen controller.

I would like to make sure whatever fix gets put in fixes all affected platforms, not just Ryzen.  I will gladly test driver/kernel patches and/or ACPI/DSDT patches.  I can also post my DSDT if it helps, it was very similar with regard to this GPIO to the one already discussed.

I have two identical laptops I can test with.
Comment 64 Luya Tshimbalanga 2018-10-30 17:19:11 UTC
(In reply to m.kolesinski from comment #63) 
> I want to be clear, this bug does not just affect Ryzen series CPUs/APUs, it
> also affects the previous gen CPUs, including the FX9800P in my x360, model
> m6-ar004dx.  It looks like they share the same GPIO config with respect to
> the i2c ELAN0734 touchscreen controller.
> 
Should the title renamed something like "Misconfigured ACPI config-table broke Elan touchscreen on HP Envy x360 series" for better clarification?
Comment 65 Aidan Hahn 2018-10-31 07:24:13 UTC
Updated title to reflect that this bug affects multiple HP x360 machines running AMD chips
Comment 66 Luya Tshimbalanga 2018-11-03 09:56:59 UTC
I just found a documentation for debugging:
https://www.kernel.org/doc/Documentation/acpi/debug.txt

Enable kernel debugging and add the parameter like "acpi.debug_layer=0x000008 acpi.debug_level=0x4" to display table information. Should there be a better parameter,please post it.
Comment 67 Fabio Tardivo 2018-11-13 03:57:55 UTC
I can provide log/debug information and test too. My notebook is HP 13M-AG0002DX.
Comment 68 Luya Tshimbalanga 2018-11-13 07:00:20 UTC
Here is an example of debugging process I have used with the help of one of kernel maintainer once installed kernel debug. It basically replaces comment #66 :

https://bugzilla.kernel.org/show_bug.cgi?id=115021#c58

I don't know exactly which .c file display acpi table. Hopefully that will draw attention once the information is submitted. Thanks in advance.
Comment 69 Hans de Goede 2018-11-19 11:40:51 UTC
First if all thank you Lukas, for pinpointing the problem. I don't see any really obvious nice answer here.

So I believe it is best to override the IRQ type manually in the AMD gpio driver to correct the acpi_get_override_irq() results from the ACPI core.

I've attached a patch doing this to bug 199523.

If someone who is seeing this issue can build and test a kernel with that patch (replacing Lukas patch) that would be great. To be clear please drop Lukas' patch  when testing mine!

If you test my patch, please provide the output of "dmesg" directly after boot and let me know if the patch fixes things (makes/keeps the touchscreen working).
Comment 70 Marc 2018-11-19 11:56:20 UTC
I would test the patch but can't find it.
Comment 71 Hans de Goede 2018-11-19 12:31:37 UTC
(In reply to Marc from comment #70)
> I would test the patch but can't find it.

My bad, I was updating the 3 different bugs about this all at the same time and I actually forgot to attach the patch, it is attached to bug 199523 now.
Comment 72 Marc 2018-11-19 14:32:09 UTC
Created attachment 279529 [details]
Output of dmesg after booting kernel 4.19.2 with new patch
Comment 73 Marc 2018-11-19 14:34:41 UTC
Unfortunately the new patch does not work on my ENVY 15-bq102ng.

I used linux kernel 4.19.2 from kernel.org, patched it with the ubuntu mainline patches and on top your patch (instead of Lukas patch).
Comment 74 Hans de Goede 2018-11-19 16:06:32 UTC
(In reply to Marc from comment #73)
> Unfortunately the new patch does not work on my ENVY 15-bq102ng.
> 
> I used linux kernel 4.19.2 from kernel.org, patched it with the ubuntu
> mainline patches and on top your patch (instead of Lukas patch).

Thank you for testing. These 2 lines in the log seem to be the problem, these happen before my patch even comes into play:

[    1.445982] amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
[    1.446019] amd_gpio: probe of AMDI0030:00 failed with error -22

With -22 being -EINVAL.

Taking a closer look at things here I think I know what is going on here.

To be continued.
Comment 75 Marc 2018-11-19 16:08:02 UTC
I am happy to test further patches.
Comment 76 Lukas Kahnert 2018-11-19 16:17:56 UTC
When I come home I will test your Patch and report asap.


(In reply to Hans de Goede from comment #74)
> (In reply to Marc from comment #73)
> > Unfortunately the new patch does not work on my ENVY 15-bq102ng.
> > 
> > I used linux kernel 4.19.2 from kernel.org, patched it with the ubuntu
> > mainline patches and on top your patch (instead of Lukas patch).
> 
> Thank you for testing. These 2 lines in the log seem to be the problem,
> these happen before my patch even comes into play:
> 
> [    1.445982] amd_gpio AMDI0030:00: Failed to get gpio IRQ: -22
> [    1.446019] amd_gpio: probe of AMDI0030:00 failed with error -22
> 
> With -22 being -EINVAL.
> 
> Taking a closer look at things here I think I know what is going on here.
> 
> To be continued.

This error happens because your patch only fixes the mis-detection of the IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529 which needs also bei fixed to get the touchscreen work.
One half of my Patch hides the affected code, so the gpio driver can probe successfully.
Comment 77 Hans de Goede 2018-11-19 16:45:24 UTC
Created attachment 279539 [details]
[PATCH] ACPI / platform: Add SMB0001 HID to forbidden_id_list

Ok second attempt, a completely different patch which I think actually is better (if it works).

Please give this one a try (without any other patches for this same issue).

Again please attach dmesg output.

If this patch does not fix things, then also please attach the output of:

ls /sys/bus/platform/devices

I would like the output of that command for both a kernel without the patch as well as for one with the patch.
Comment 78 Hans de Goede 2018-11-19 17:04:48 UTC
(In reply to Lukas Kahnert from comment #76)
> This error happens because your patch only fixes the mis-detection of the
> IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529
> which needs also bei fixed to get the touchscreen work.

Right, I figured that out now, actually I believe that with your hack to drivers/acpi/resource.c the changes you made to drivers/base/platform.c should no longer be necessary.

We've been looking at the wrong part of the DSDT the culprit is not:

Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000007,
                    }

This uses an extended interrupt syntax, so acpi_dev_get_irqresource() gets called with legacy == false and the troublesome acpi_get_override_irq()
never happens.

I believe the real culprit is:

    Scope (_SB.PCI0)
    {
        Device (SMBD)
        {
            Name (_HID, "SMB0001")  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0B20,             // Range Minimum
                    0x0B20,             // Range Maximum
                    0x20,               // Alignment
                    0x20,               // Length
                    )
                IRQ (Level, ActiveLow, Shared, )
                    {7}
            })
        }
    }

Which does use a legacy style IRQ resource, this causes acpi_dev_get_irqresource() to be called with legacy == true and then the troublesome acpi_get_override_irq() happens.

I believe that this troublesome node gets parsed before the AMDI0030 node and then by the time the AMDI0030 node happens, inside acpi_dev_get_irqresource() we hit the else of:

        irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
        if (irq >= 0) {
                res->start = irq;
                res->end = irq;
        } else {
                acpi_dev_irqresource_disabled(res, gsi);
        }

Which sets the DISABLED flag, which is causing the issue in drivers/base/platform.c . The reason we hit the else path is because of the earlier enumeration of the same interrupt with conflicting trigger / polarity settings so the second one fails with -EBUSY (it would work if the flags would match).

My new attempt deals with this by adding the "SMB0001" HID to the blacklist for creating platform devices, so that acpi_dev_get_resources() does not get called on it at all, avoiding the call of acpi_dev_get_irqresource() with legacy == false.

The not creating of a platform_device for the "SMB0001" HID is not an issue since the driver for it is an acpi bus driver not a platform bus driver.
Comment 79 Marc 2018-11-19 17:06:42 UTC
Created attachment 279541 [details]
Output of dmesg after booting kernel 4.19.2 with new patch v2 (touchscreen works)

Congratulations, this work!
Comment 80 Hans de Goede 2018-11-19 17:09:30 UTC
(In reply to Marc from comment #79)
> Created attachment 279541 [details]
> Output of dmesg after booting kernel 4.19.2 with new patch v2 (touchscreen
> works)
> 
> Congratulations, this work!

Great and the "ACPI: IRQ 7 override to edge, high" message is gone. So you've proven my theory.

Now I need to improve the commit message and then this patch can be submitted upstream.
Comment 81 Hans de Goede 2018-11-19 17:53:02 UTC
p.s.

I plan to add the following to the commit msg, please let me know if you've objections against this:

Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
Tested-by: Marc <suaefar@googlemail.com>
Comment 82 Lukas Kahnert 2018-11-19 18:20:26 UTC
(In reply to Hans de Goede from comment #78)
> (In reply to Lukas Kahnert from comment #76)
> > This error happens because your patch only fixes the mis-detection of the
> > IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529
> > which needs also bei fixed to get the touchscreen work.
> 
> Right, I figured that out now, actually I believe that with your hack to
> drivers/acpi/resource.c the changes you made to drivers/base/platform.c
> should no longer be necessary.
> 
> We've been looking at the wrong part of the DSDT the culprit is not:
> 
> Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
>                     {
>                         0x00000007,
>                     }
> 
> This uses an extended interrupt syntax, so acpi_dev_get_irqresource() gets
> called with legacy == false and the troublesome acpi_get_override_irq()
> never happens.
> 
> I believe the real culprit is:
> 
>     Scope (_SB.PCI0)
>     {
>         Device (SMBD)
>         {
>             Name (_HID, "SMB0001")  // _HID: Hardware ID
>             Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource
> Settings
>             {
>                 IO (Decode16,
>                     0x0B20,             // Range Minimum
>                     0x0B20,             // Range Maximum
>                     0x20,               // Alignment
>                     0x20,               // Length
>                     )
>                 IRQ (Level, ActiveLow, Shared, )
>                     {7}
>             })
>         }
>     }
> 
> Which does use a legacy style IRQ resource, this causes
> acpi_dev_get_irqresource() to be called with legacy == true and then the
> troublesome acpi_get_override_irq() happens.
> 
> I believe that this troublesome node gets parsed before the AMDI0030 node
> and then by the time the AMDI0030 node happens, inside
> acpi_dev_get_irqresource() we hit the else of:
> 
>         irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
>         if (irq >= 0) {
>                 res->start = irq;
>                 res->end = irq;
>         } else {
>                 acpi_dev_irqresource_disabled(res, gsi);
>         }
> 
> Which sets the DISABLED flag, which is causing the issue in
> drivers/base/platform.c . The reason we hit the else path is because of the
> earlier enumeration of the same interrupt with conflicting trigger /
> polarity settings so the second one fails with -EBUSY (it would work if the
> flags would match).
> 
> My new attempt deals with this by adding the "SMB0001" HID to the blacklist
> for creating platform devices, so that acpi_dev_get_resources() does not get
> called on it at all, avoiding the call of acpi_dev_get_irqresource() with
> legacy == false.
> 
> The not creating of a platform_device for the "SMB0001" HID is not an issue
> since the driver for it is an acpi bus driver not a platform bus driver.

Thanks for this good explanation :)

I can also confirm that your patch works on my laptop

(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
> Tested-by: Marc <suaefar@googlemail.com>

I'm glad that I could help :)
Comment 83 Fabio Tardivo 2018-11-19 22:45:01 UTC
(In reply to Hans de Goede from comment #77)
> Created attachment 279539 [details]
> [PATCH] ACPI / platform: Add SMB0001 HID to forbidden_id_list
> 
> Ok second attempt, a completely different patch which I think actually is
> better (if it works).
> 
> Please give this one a try (without any other patches for this same issue).
> 
> Again please attach dmesg output.
> 
> If this patch does not fix things, then also please attach the output of:
> 
> ls /sys/bus/platform/devices
> 
> I would like the output of that command for both a kernel without the patch
> as well as for one with the patch.

It worked also on mine HP 13M-AG0002DX.
Comment 84 Stephen Owusu 2018-11-20 08:51:06 UTC
I tried to apply a patch but the kernel fails to compile. It only generated the headers file. There was a recipe for target error for retpoline-check-generic. Anyone know how I can fix this? Also, I am very new to all this but how long does a patch submission to appear in the next release?
Comment 85 Stephen Owusu 2018-11-20 08:51:45 UTC
I tried to apply a patch but the kernel fails to compile. It only generated the headers file. There was a recipe for target error for retpoline-check-generic. Anyone know how I can fix this? Also, I am very new to all this but how long does a patch submission to appear in the next release?
Comment 86 Marc 2018-11-20 15:33:28 UTC
(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
> Tested-by: Marc <suaefar@googlemail.com>

I have no objections.
Thanks to everybody for finding a solution here :)
Comment 87 Maxime 2018-11-21 10:21:43 UTC
I applied the latest patch, it works but it makes my touchscreen show up as having a battery that's at 0%. The previous patch had the same behaviour on my system.
Comment 88 Hans de Goede 2018-11-21 10:38:38 UTC
(In reply to Maxime from comment #87)
> I applied the latest patch, it works but it makes my touchscreen show up as
> having a battery that's at 0%. The previous patch had the same behaviour on
> my system.

Good to hear that this patch works for you to.

The battery at 0% is an unrelated issue, please file a new bug against product Drivers component HID (or input if there is no HID component) for this.
Comment 89 David Pedersen 2018-11-21 22:42:42 UTC
(In reply to Hans de Goede from comment #81)
> p.s.
> 
> I plan to add the following to the commit msg, please let me know if you've
> objections against this:
> 
> Reported-by: Lukas Kahnert <openproggerfreak@gmail.com>
> Tested-by: Marc <suaefar@googlemail.com>

I can also verify that the patch works on my HP Envy x360 15-bq100 Convertible! Thanks all, especially Hans and Lukas for a job well done!
Comment 90 David Pedersen 2018-11-21 23:09:11 UTC
(In reply to Stephen Owusu from comment #85)
> I tried to apply a patch but the kernel fails to compile. It only generated
> the headers file. There was a recipe for target error for
> retpoline-check-generic. Anyone know how I can fix this? Also, I am very new
> to all this but how long does a patch submission to appear in the next
> release?

I had a similar problem building on one machine and had to work through the missing packages to get a (nearly) complete build. Building on a fresh install of Ubuntu Xenial worked much better, without the problems of missing/mismatched packages. 

In both cases, I ended up with 7 deb files which installed and worked fine. The final perarch deb build failed, but doesn't seem to affect my system in any way that I've found so far. If anyone knows whether that's a problem, I'd like to know... The failure was a missing stdarg.h from the kernel.h include while building the perarch deb.
Comment 91 Luya Tshimbalanga 2018-11-23 03:09:20 UTC
(In reply to Maxime from comment #87)
> I applied the latest patch, it works but it makes my touchscreen show up as
> having a battery that's at 0%. The previous patch had the same behaviour on
> my system.

Similar bug on https://bugzilla.kernel.org/show_bug.cgi?id=201121
It looks like the issue affecting Elan touchscreen and stylus models.
Comment 92 Maxime 2018-11-24 14:34:06 UTC
(In reply to Hans de Goede from comment #88)
> (In reply to Maxime from comment #87)
> > I applied the latest patch, it works but it makes my touchscreen show up as
> > having a battery that's at 0%. The previous patch had the same behaviour on
> > my system.
> 
> Good to hear that this patch works for you to.
> 
> The battery at 0% is an unrelated issue, please file a new bug against
> product Drivers component HID (or input if there is no HID component) for
> this.

What do you mean with a HID component in this case? A stylus?
Comment 93 Hans de Goede 2018-11-24 14:40:13 UTC
(In reply to Maxime from comment #92)
> What do you mean with a HID component in this case? A stylus?

I mean the Product and Component fields in bugzilla, for the new bug. E.g. this bug has Product set the ACPI and Component set to Config-Tables.
Comment 94 Lukas Kahnert 2018-11-26 08:29:10 UTC
*** Bug 199529 has been marked as a duplicate of this bug. ***
Comment 95 tabuvudu 2018-11-27 04:43:15 UTC
HP envy x360 13-ag0018au with Ryzen 7 here, the touchscreen issue is resolved with BIOS F.21.Rev.A and standard fedora kernel-4.19.3-300.fc29.x86_64
Comment 96 Addie Morrison 2018-11-27 19:14:26 UTC
Is anyone else seeing the issue where the touchscreen/pen don't work when the computer is first powered on (needs to be rebooted at least once)? If so, was this supposed to be fixed by this or should that be a separate bug report?
Comment 97 Hans de Goede 2018-11-27 19:27:11 UTC
(In reply to Addie Morrison from comment #96)
> Is anyone else seeing the issue where the touchscreen/pen don't work when
> the computer is first powered on (needs to be rebooted at least once)? If
> so, was this supposed to be fixed by this or should that be a separate bug
> report?

When this happens do you see any relevant messages in dmesg ?

In: https://bugzilla.redhat.com/show_bug.cgi?id=1644013

There is a report of the machine sometimes reporting:

[    5.739281] irq 7: nobody cared (try booting with the "irqpoll" option)
[    5.739284] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G         C        4.19.2-301.hdg1.fc29.x86_64 #1
[    5.739285] Hardware name: HP HP ENVY x360 Convertible 15-cp0xxx/8497, BIOS F.21 10/19/2018
[    5.739285] Call Trace:
[    5.739288]  <IRQ>
[    5.739294]  dump_stack+0x5c/0x80
[    5.739297]  __report_bad_irq+0x37/0xae
[    5.739298]  note_interrupt.cold.9+0xa/0x69
[    5.739300]  handle_irq_event_percpu+0x6a/0x80
[    5.739301]  handle_irq_event+0x27/0x44
[    5.739302]  handle_fasteoi_irq+0x7f/0x120
[    5.739305]  handle_irq+0xbf/0x100
[    5.739307]  do_IRQ+0x49/0xd0
[    5.739308]  common_interrupt+0xf/0xf
[    5.739309]  </IRQ>

After which the kernel disables IRQ 7 causing the touchscreen to not work again. 

If you're seeing this too, please open a new bug for the "irq 7: nobody cared" problem.

The patch fixing the IRQ not being assigned to the GPIO controller has been merged upstream now, so I'm closing this bug.
Comment 98 m.kolesinski 2018-11-28 22:33:22 UTC
I was able to test the latest patch from Hans on Arch Linux with 4.19.4-arch1 on my HP M6-AR004DX AMD FX-9800p laptop, and can confirm that the ELAN0732 touchscreen finally works!  No need for the ACPI/DSDT edits.  No more GPIO errors in journalctl, and the device was detected and installed with hid_multitouch.

To add icing to the cake, it even worked on the login screen (GDM) and within Gnome 3, with no manual configuration steps required, and no calibration required.

I had a bear of a time testing the patch this time (no issue with the patch itself); the latest Arch build scripts have moved to pulling kernel source via a git clone (massive download...multiple gigs...I have a relatively slow connection, and git clone offers no restart ability if the download times out or fails partway...).  I had to manually download source with http and hack PKGBUILD to point at my local source copy (the latest Arch PKGBUILD also points to a newer kernel than the latest Arch release...seems like a problem), in addition to adding the patch file to prepare().
Comment 99 Bram Coenen 2018-11-29 18:45:42 UTC
(In reply to Hans de Goede from comment #97)
> (In reply to Addie Morrison from comment #96)
> > Is anyone else seeing the issue where the touchscreen/pen don't work when
> > the computer is first powered on (needs to be rebooted at least once)? If
> > so, was this supposed to be fixed by this or should that be a separate bug
> > report?
> 
> When this happens do you see any relevant messages in dmesg ?
> 
> In: https://bugzilla.redhat.com/show_bug.cgi?id=1644013
> 
> There is a report of the machine sometimes reporting:
> 
> [    5.739281] irq 7: nobody cared (try booting with the "irqpoll" option)
> [    5.739284] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G         C       
> 4.19.2-301.hdg1.fc29.x86_64 #1
> [    5.739285] Hardware name: HP HP ENVY x360 Convertible 15-cp0xxx/8497,
> BIOS F.21 10/19/2018
> [    5.739285] Call Trace:
> [    5.739288]  <IRQ>
> [    5.739294]  dump_stack+0x5c/0x80
> [    5.739297]  __report_bad_irq+0x37/0xae
> [    5.739298]  note_interrupt.cold.9+0xa/0x69
> [    5.739300]  handle_irq_event_percpu+0x6a/0x80
> [    5.739301]  handle_irq_event+0x27/0x44
> [    5.739302]  handle_fasteoi_irq+0x7f/0x120
> [    5.739305]  handle_irq+0xbf/0x100
> [    5.739307]  do_IRQ+0x49/0xd0
> [    5.739308]  common_interrupt+0xf/0xf
> [    5.739309]  </IRQ>
> 
> After which the kernel disables IRQ 7 causing the touchscreen to not work
> again. 
> 
> If you're seeing this too, please open a new bug for the "irq 7: nobody
> cared" problem.
> 
> The patch fixing the IRQ not being assigned to the GPIO controller has been
> merged upstream now, so I'm closing this bug.


First of all thank you helping out Hans. I got the same problem with "irq 7: nobody cared" and made a bug report over here: https://bugzilla.kernel.org/show_bug.cgi?id=201817 . I'm new to bug reporting, so I hope I did it right!
Comment 100 Hans de Goede 2018-11-30 09:40:43 UTC
(In reply to Bram Coenen from comment #99)
> First of all thank you helping out Hans. I got the same problem with "irq 7:
> nobody cared" and made a bug report over here:
> https://bugzilla.kernel.org/show_bug.cgi?id=201817 . I'm new to bug
> reporting, so I hope I did it right!

Thanks, lets continue this in the new bug.

Note You need to log in before you can comment on or make changes to this bug.