Bug 199911

Summary: Razer Blade 15 2018 touchpad support (GPIO can't be used as IRQ)
Product: Drivers Reporter: jamir (soundhermit)
Component: Input DevicesAssignee: Andy Shevchenko (andy.shevchenko)
Status: RESOLVED CODE_FIX    
Severity: normal CC: 2009, ameynarkhede02, andy.shevchenko, bbriniotis, benjamin.tissoires, bugzilla, eug5ne, gschram, janus.reith, jon.snow, jwrdegoede, kai.heng.feng, mika.westerberg, mootnewt, mrhieu059, qiao.bo, radek, simon.detheridge, trave5, victor, yunying.sun
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 4.18_rc1 Subsystem:
Regression: No Bisected commit-id:
Bug Depends on:    
Bug Blocks: 200663, 200787    
Attachments: Files collected during investigation
dmesg
i2cdetect
i2c_hw_id
windows_gpio2_inf
windows_i2c_inf
lsusb
touchpad_hw_id
acpi dump
pins
gpio-ranges
Add more debugging to gpiolib-acpi.c
dmesg_with gpiolib-acpi_patch
dmesg with overriding pin 100 with 79
Skip ACPI check in pintctrl driver
dmesg_skip_acpi_check_pinctrl
dmesg with 22 and 26 - works
Interrupts after boot
Interrupts after mouse events
Pins with driver loaded
Translation fix for gpiochip_lock_as_irq()
dmesg after translation fix
Patch file used to test.
Hardware ID
dmesg from ASUS GL703GE
dmesg from ASUS GL703GE
i2cdetect from ASUS GL703GE
/proc/interrupts from ASUS GL703GE
inteltool from ASUS GL703GE
gpio pins from GL703GE
gpio ranges from GL703GE
acpidump -o table.dat from GL703GE
grep -H 15 /sys/bus/acpi/devices/*/status from GL703GE
Fix community ordering for H variant
Interrupts after working patch from ASUS GL703GE
iomem after working patch from ASUS GL703GE
gpio-pins after working patch from ASUS GL703GE
gpio-ranges after working patch from ASUS GL703GE
post-patch dmesg output for GK5CN5Z
pre-patch dmesg output for GK5CN5Z
/proc/interrupts on GK5CN5Z
/sys/kernel/debug/gpio on GK5CN5Z
/sys/kernel/debug/pinctrl/INT3450:00/pins on GK5CN5Z post-patch
dsdt_before_after
Fix CNL-H HOSTSW_OWN offset
pinctrl-intel-Fix-pin-translation-when-requesting-IR.patch
dmesg on th HP zBook x360, withoutgpio translation fixes
pinctrl: cannonlake: Fix HOSTSW_OWN register offset of H variant
Revert "pinctrl: intel: Do pin translation when lock IRQ"
dmesg_hp_zbook_studio_g5

Description jamir 2018-06-03 17:46:08 UTC
Razer Blade 15 2018 touchpad support [1532:0233]

Bus 001 Device 005: ID 1532:0233 Razer USA, Ltd 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x1532 Razer USA, Ltd
  idProduct          0x0233 
  bcdDevice            2.00
  iManufacturer           1 Razer
  iProduct                2 Razer Blade
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0054
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      61
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      1 Keyboard
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     159
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      94
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0000
  (Bus Powered)
Comment 1 jamir 2018-06-24 18:56:55 UTC
Created attachment 276785 [details]
Files collected during investigation
Comment 2 jamir 2018-06-24 18:57:54 UTC
Investigation done by alkersan 
-----------------------------------

The touchpad of the Razer Blade 15 (2018) laptop is unresponsive after boot.

After shallow investigation of hardware identifiers, the touchpad seems to be present the USB and I2C buses.

The USB part is visible as a HID device and includes a mouse interface, but it probably handles just the keys of the laptop, including the keyboard, media/function buttons and RGB backlight programming.
The detailed output of lsusb is attached. It has an ID [1532:0233] where 1532 stands for Razer Inc. and 0233 is a yet unknown device. Similarly to 0232, which Openrazer project identifies as a keybard of the previous 2017 Blade laptop (https://github.com/openrazer/openrazer/blob/master/driver/razerkbd_driver.h#L143). Thus a USB HID part is probably out of interest for now.

The i2c interface is presumably responsible for the touch positioning. It's mentioned in the dmesg.log surrounded with the vdd supply and interrupt errors of the so called i2c-1A582000 device. The i2c bus tree and the i2cdetect output is attached.

Another interesting detail lies in the touchpad behavior in the Windows OS. The laptop is bundled with a plenty of drivers and is fully functional from the factory. But after the clean Windows installation - touchpad is unresponsive also. The required driver to enable the touchpad is an Intel Serial IO Driver (http://drivers.razersupport.com//index.php?_m=downloads&_a=viewdownload&downloaditemid=2878&nav=0,350,765,766). It's comprised of 4 parts: GPIO, I2C, SPI and UART. Only GPIO and I2C are required for the touchpad to become responsive without reboot (INF files of these drivers are attached). Right after installation Windows detects the touchpad as an I2C HID Device and HID-Complaint touch pad (the device manager screenshots are attached). Both devices has a id 1A58:2000, appeared previosly in the kernel log.
Comment 3 jamir 2018-06-24 19:07:05 UTC
Created attachment 276789 [details]
dmesg
Comment 4 jamir 2018-06-24 19:07:28 UTC
Created attachment 276791 [details]
i2cdetect
Comment 5 jamir 2018-06-24 19:07:56 UTC
Created attachment 276793 [details]
i2c_hw_id
Comment 6 jamir 2018-06-24 19:08:25 UTC
Created attachment 276795 [details]
windows_gpio2_inf
Comment 7 jamir 2018-06-24 19:08:42 UTC
Created attachment 276797 [details]
windows_i2c_inf
Comment 8 jamir 2018-06-24 19:08:56 UTC
Created attachment 276799 [details]
lsusb
Comment 9 jamir 2018-06-24 19:09:15 UTC
Created attachment 276801 [details]
touchpad_hw_id
Comment 10 jamir 2018-06-29 06:13:22 UTC
Created attachment 277029 [details]
acpi dump
Comment 11 Mika Westerberg 2018-06-29 10:01:53 UTC
Can you also attach content of /sys/kernel/debug/pinctrl/INT3450:00/pins and /sys/kernel/debug/pinctrl/INT3450:00/gpio-ranges?
Comment 12 jamir 2018-06-29 13:32:09 UTC
Created attachment 277051 [details]
pins
Comment 13 jamir 2018-06-29 13:32:26 UTC
Created attachment 277053 [details]
gpio-ranges
Comment 14 jamir 2018-06-29 13:32:45 UTC
added pins and gpio-ranges
Comment 15 Mika Westerberg 2018-06-29 14:13:57 UTC
Created attachment 277055 [details]
Add more debugging to gpiolib-acpi.c

Can you try the attached patch and then attach dmesg again? It should print the GPIO number we get from the BIOS.
Comment 16 jamir 2018-06-29 14:34:05 UTC
Created attachment 277057 [details]
dmesg_with gpiolib-acpi_patch
Comment 17 jamir 2018-06-29 16:12:37 UTC
pin = 100
Comment 18 Andy Shevchenko 2018-07-02 23:12:17 UTC
This pin is configured by BIOS as GPIO direct interrupt to IOAPIC (SCI mode).
So, there is coupled GpioInt() and Interrupt() resources. If I read DSDT correctly the IRQ resource, which must be used, depends on the setting of some internal variable. My understanding that, since the pin is configured to generate SCI, the driver should respect BIOS settings.
Comment 19 Andy Shevchenko 2018-07-03 01:44:45 UTC
Okay, more investigation on the message "flag is output". It seems that in the driver we missed the fact of IRQ to pin translation in one case. That's why we are actually talking to hadrware pin 100 (ACPI 129) instead of pin 79 (ACPI 100). And that pin is indeed configured as output.

But I need to confirm this, because it's early morning and I even managed to send a patch to mailing list (related to this, but not fixing) with a completely wrong commit message. Need some sleep for sure.
Comment 20 Andy Shevchenko 2018-07-03 01:45:41 UTC
Take the bug as it seems to be related to our GPIO/pinctrl driver.
Comment 21 jamir 2018-07-03 01:59:53 UTC
Let me know if you need me to try out anything.
Comment 22 Andy Shevchenko 2018-07-03 23:50:25 UTC
(In reply to jamir from comment #21)
> Let me know if you need me to try out anything.

Can you add to the top of gpiochip_lock_as_irq() the following hack and try to boot again (we need dmesg with 'ignore_loglevel' added to the kernel command line):

if (offset == 100)
 offset = 79;
Comment 23 jamir 2018-07-04 00:02:32 UTC
Created attachment 277159 [details]
dmesg with overriding pin 100 with 79
Comment 24 jamir 2018-07-04 00:07:15 UTC
the touchpad is still not functional I have attached the dmesg after the change.
Comment 25 jamir 2018-07-04 00:27:17 UTC
The error code is different this time though - 

i2c_hid: probe of i2c-1A582000:00 failed with error -1 instead of -22
Comment 26 Mika Westerberg 2018-07-06 11:14:52 UTC
Created attachment 277217 [details]
Skip ACPI check in pintctrl driver

Can you try the attached patch and see if anything changes? Then attach dmesg again.
Comment 27 jamir 2018-07-06 14:07:21 UTC
Created attachment 277227 [details]
dmesg_skip_acpi_check_pinctrl
Comment 28 Andy Shevchenko 2018-07-06 14:43:41 UTC
(In reply to jamir from comment #27)
> Created attachment 277227 [details]
> dmesg_skip_acpi_check_pinctrl

Thanks, it looks like we missed to ask you to apply both
- patch from comment #22, AND
- patch from comment #26

together and try.

Sorry it takes more effort than we assumed.
Comment 29 jamir 2018-07-06 15:04:07 UTC
gpiochip_lock_as_irq() doesn't exist in gpiolib-acpi.c anymore on rc3. Do you know where this function moved to? I see a call from the gpiolib-acpi.
Comment 30 jamir 2018-07-06 15:07:35 UTC
found it I think its in gpiolib.c
Comment 31 jamir 2018-07-06 15:14:56 UTC
Created attachment 277229 [details]
dmesg with 22 and 26 - works

Wow, the touchpad is working!!!

Touchpad mouse movement functional.
Touchpad left mouse button functional.
Touchpad right mouse button functional.
Touchpad 2 finger scroll functional.
Touchpad tap to click, not functional, don't see a setting on gnome settings to enable that.
Comment 32 Andy Shevchenko 2018-07-06 22:47:17 UTC
There are two issues at once that’s why two hacks. But to see picture better, can you please attach cat /proc/interrupt output after just boot, and after a bit so events, like touching, doing some gestures?
Also attach a pins file again with driver loaded.

All above from _working_ case, thanks!
Comment 33 Joe DeVivo 2018-07-06 23:15:14 UTC
Can these patches be backported to 4.17 or are there other things in 4.18 that are necessary for the fix?
Comment 34 jamir 2018-07-07 00:22:55 UTC
Created attachment 277261 [details]
Interrupts after boot
Comment 35 jamir 2018-07-07 00:23:23 UTC
Created attachment 277263 [details]
Interrupts after mouse events
Comment 36 jamir 2018-07-07 00:23:55 UTC
Created attachment 277265 [details]
Pins with driver loaded
Comment 37 jamir 2018-07-07 00:24:10 UTC
(In reply to Andy Shevchenko from comment #32)
> There are two issues at once that’s why two hacks. But to see picture
> better, can you please attach cat /proc/interrupt output after just boot,
> and after a bit so events, like touching, doing some gestures?
> Also attach a pins file again with driver loaded.
> 
> All above from _working_ case, thanks!

done.
Comment 38 jamir 2018-07-07 00:48:45 UTC
More observations:

I see lockups sometimes when restarting just before X starts (I have seen it now 4 times). I have to hold the power button and reboot and then the next time it detects the touchpad fine.

When it is locks up I see "supply vdd not found, using dummy regulator" message.


When I enable wayland in GDM (custom.conf) and gnome shell I see the option "tap to click" and enabling it enables the tap to click. 

I was xorg for two reasons mutter/clutter caps the refresh rate to 60. and open broadcasting app doesn't record wayland composited desktop (shows black screen).
Comment 39 jamir 2018-07-07 02:48:52 UTC
one more data point.

The lockup only seems to occur when I reboot the laptop. If I shutdown and power it back on I've been able to successfully start the OS like 7 times in a row without lockup.
Comment 40 Mika Westerberg 2018-07-09 09:20:34 UTC
So I think the touchpad locking is most likely not related and for that you should file another bugzilla entry.

Regarding the touchpad interrupt via GPIO we have two issues:

  - BIOS has configured the pin incorrectly to be owned by ACPI. Regardless it 
    seems that we can just skip checking for that bit in Linux driver as well 
    because interrupts still work (we may want to log something to dmesg about 
    this, though).

  - We do not map hwirq correctly in gpiochip_lock_as_irq() when
    get_direction() is called.

We will work a proper fix for the two but it may take some time as I will be on vacation next 3 weeks.
Comment 41 jamir 2018-07-09 13:58:56 UTC
Sounds good.
Comment 42 Andy Shevchenko 2018-07-23 12:39:51 UTC
Summon Hans WRT https://bugzilla.redhat.com/show_bug.cgi?id=1543769#c117
Comment 43 Andy Shevchenko 2018-07-24 21:04:46 UTC
Created attachment 277483 [details]
Translation fix for gpiochip_lock_as_irq()

@jamir, can you, please, test this patch instead of one in comment #22 (you still need another one from comment #26!)?
Comment 44 jamir 2018-07-25 01:29:51 UTC
Created attachment 277485 [details]
dmesg after translation fix

The touchpad is functional after the translation fix.

dmesg captured with only patch applied to the pinctrl-intel.c.

Started with a clean tree without the below hack.

if (offset == 100)
 offset = 79;
Comment 45 Andy Shevchenko 2018-07-25 09:13:14 UTC
Let me understand, you applied the only translation patch _without_ one from comment #26 and everything still works?
Comment 46 jamir 2018-07-25 12:59:12 UTC
I applied the translation and skipping ACPI check both.
Comment 47 Mika Westerberg 2018-07-25 15:16:25 UTC
Just to be sure. You only have one patch applied and it is the translation from from Andy in comment #43? You don't have the patch in comment #26 applied?
Comment 48 jamir 2018-07-25 15:24:57 UTC
Created attachment 277507 [details]
Patch file used to test.

I am attaching the patch file I used to test.
Comment 49 Andy Shevchenko 2018-07-25 15:41:35 UTC
(In reply to jamir from comment #48)
> Created attachment 277507 [details]
> Patch file used to test.
> 
> I am attaching the patch file I used to test.

Thanks for your patience! Now it's clear.

The translation patch has been sent to upstream today (we expect maintainer take it soon). The ACPI hack needs to be thought about a bit longer. We are waiting for some elaboration internally from other team.
Comment 50 Marc Landolt 2018-07-25 16:54:34 UTC
Hello

Andy Shevchenko said in a thread on redhat bugtracker that this could maybe also the solution for my problem:

The Hardware is different:
ASUS GL703GE Laptop

if you need more data i will be pleased to submit logfiles or whatever needet. i could also open a teamviewer session or something like that if this helps resolving the problem on my hardware.

in windows and bios the touchpad works but not on linux, not on debian, not on fedora, not on ubuntu...
Comment 51 Andy Shevchenko 2018-07-25 16:59:45 UTC
(In reply to Marc Landolt from comment #50)
> if you need more data i will be pleased to submit logfiles or whatever
> needet.

Provide the same set of data we asked from @jamir, i.e. gpio-ranges, pins, and /proc/interrupts files. 

Meanwhile try to apply just one patch @jamir attached in comment #48.
Comment 52 Marc Landolt 2018-07-25 17:15:03 UTC
Created attachment 277509 [details]
Hardware ID
Comment 53 Marc Landolt 2018-07-25 17:17:26 UTC
Created attachment 277511 [details]
dmesg from ASUS GL703GE

with modifications
Comment 54 Marc Landolt 2018-07-25 17:17:50 UTC
Created attachment 277513 [details]
dmesg from ASUS GL703GE

without modifications
Comment 55 Marc Landolt 2018-07-25 17:18:24 UTC
Created attachment 277515 [details]
i2cdetect from ASUS GL703GE
Comment 56 Marc Landolt 2018-07-25 17:19:44 UTC
how to generate the gpio-ranges file?
Comment 57 Marc Landolt 2018-07-25 17:35:13 UTC
Created attachment 277517 [details]
/proc/interrupts from ASUS GL703GE
Comment 58 Marc Landolt 2018-07-25 17:40:24 UTC
Created attachment 277519 [details]
inteltool from ASUS GL703GE
Comment 59 Andy Shevchenko 2018-07-25 17:51:54 UTC
(In reply to Marc Landolt from comment #56)
> how to generate the gpio-ranges file?

It’s under /sys/kernel/debug/pinctrl/INT3450:00/ There also most important one called pins. You need to mount debugged before looking for them.
Comment 60 Marc Landolt 2018-07-25 18:27:55 UTC
Created attachment 277527 [details]
gpio pins from GL703GE
Comment 61 Marc Landolt 2018-07-25 18:28:20 UTC
Created attachment 277529 [details]
gpio ranges from GL703GE
Comment 62 Marc Landolt 2018-07-25 18:28:45 UTC
the 4.18.rc6 with the patch you said is compiled now, boots but no touchpad

[   13.206001] idma64 idma64.0: Found Intel integrated DMA 64-bit
[   13.209068] cannonlake-pinctrl INT3450:00: pin 225 for irq (hwirq=297)
[   13.209126] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not found, using dummy regulator
[   13.210398] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: tried to flag a GPIO set as output for IRQ
[   13.210424] cannonlake-pinctrl INT3450:00: unable to lock HW IRQ 225 for IRQ
[   13.210440] genirq: Failed to request resources for ELAN1200:00 (irq 138) on irqchip intel-gpio
[   13.210468] i2c_hid i2c-ELAN1200:00: Could not register for ELAN1200:00 interrupt, irq = 138, ret = -22
[   13.210486] i2c_hid: probe of i2c-ELAN1200:00 failed with error -22
[   13.212565] mei_me 0000:00:16.0: enabling device (0000 -> 0002)
Comment 63 Andy Shevchenko 2018-07-25 18:47:49 UTC
(In reply to Marc Landolt from comment #62)
> the 4.18.rc6 with the patch you said is compiled now, boots but no touchpad
> 
> [   13.206001] idma64 idma64.0: Found Intel integrated DMA 64-bit
> [   13.209068] cannonlake-pinctrl INT3450:00: pin 225 for irq (hwirq=297)
> [   13.209126] i2c_hid i2c-ELAN1200:00: i2c-ELAN1200:00 supply vdd not
> found, using dummy regulator
> [   13.210398] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: tried to
> flag a GPIO set as output for IRQ
> [   13.210424] cannonlake-pinctrl INT3450:00: unable to lock HW IRQ 225 for
> IRQ
> [   13.210440] genirq: Failed to request resources for ELAN1200:00 (irq 138)
> on irqchip intel-gpio
> [   13.210468] i2c_hid i2c-ELAN1200:00: Could not register for ELAN1200:00
> interrupt, irq = 138, ret = -22
> [   13.210486] i2c_hid: probe of i2c-ELAN1200:00 failed with error -22
> [   13.212565] mei_me 0000:00:16.0: enabling device (0000 -> 0002)

Thanks.

What we need is the output file of `acpidump -o table.dat` and output of the command `grep -H 15 /sys/bus/acpi/devices/*/status`. Also, please, check BIOS settings: if anything has choice between linux and windows, choose windows.
Comment 64 Marc Landolt 2018-07-25 18:49:03 UTC
Created attachment 277531 [details]
acpidump -o table.dat from GL703GE
Comment 65 Marc Landolt 2018-07-25 18:49:48 UTC
Created attachment 277533 [details]
grep -H 15 /sys/bus/acpi/devices/*/status from GL703GE
Comment 66 Andy Shevchenko 2018-07-26 14:09:32 UTC
Created attachment 277553 [details]
Fix community ordering for H variant

Another patch for Cannonlake PCH-H.
Comment 67 Andy Shevchenko 2018-07-26 14:12:07 UTC
(In reply to Marc Landolt from comment #64)
> Created attachment 277531 [details]
> acpidump -o table.dat from GL703GE

Thanks, that is helpful.

Can you test another patch from comment #66 (on top of the one from comment #48) and share the
- output of `cat /proc/interrupts /proc/iomem`
- *gpio-ranges* and *pins* files

?

@jamir, if you can test that patch as well to see it doesn't break your case. Thanks!
Comment 68 Marc Landolt 2018-07-26 16:30:35 UTC
(In reply to Andy Shevchenko from comment #66)
> Created attachment 277553 [details]
> Fix community ordering for H variant
> 
> Another patch for Cannonlake PCH-H.

Yay, GREAT, Andy you're a Genius, the Touchpad is working :)

After Downloading Kernel 4.18.RC6, patching with https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff and https://bugzilla.kernel.org/attachment.cgi?id=277553&action=diff it's working.

-Tap to click works
-2 Finger scroll works (only Natural Scrolling, always on)
-2 Finger right click works
-left mouse button works
-right mouse button does not work but with 2 finger click it works
-Edge Scrolling does not work
-it disconects from time to time (rmmod -r hid-multitouch && modprobe hid-multitouch helps)

shall I test other patches and do you still need the outputs from Comment 67 (interrupts, iomem, ranges, pins?

With kind regards and many thanks so far
Marc Landolt
Comment 69 Andy Shevchenko 2018-07-26 16:46:24 UTC
(In reply to Marc Landolt from comment #68)
> (In reply to Andy Shevchenko from comment #66)
> > Created attachment 277553 [details]
> > Fix community ordering for H variant
> > 
> > Another patch for Cannonlake PCH-H.
> 
> Yay, GREAT, Andy you're a Genius, the Touchpad is working :)

Sorry it wasn't working from the day 1.

> shall I test other patches

Nothing to test for now. There are three problems in your case and one of them doesn't clear yet (in a sense of root cause). That's, we are discussing internally and will come up with workaround / solution later on.

> and do you still need the outputs from Comment 67
> (interrupts, iomem, ranges, pins?

Yes, please.
Comment 70 Marc Landolt 2018-07-26 16:55:18 UTC
Created attachment 277555 [details]
Interrupts after working patch from ASUS GL703GE
Comment 71 Marc Landolt 2018-07-26 16:55:39 UTC
Created attachment 277557 [details]
iomem after working patch from ASUS GL703GE
Comment 72 Marc Landolt 2018-07-26 16:56:02 UTC
Created attachment 277559 [details]
gpio-pins after working patch from ASUS GL703GE
Comment 73 Marc Landolt 2018-07-26 16:56:27 UTC
Created attachment 277561 [details]
gpio-ranges after working patch from ASUS GL703GE
Comment 74 Marc Landolt 2018-07-26 19:16:55 UTC
There are still some issues, I guess it are the same issues that are also on the GL503VS and maybe in a different part of the kernel (not sure):

Problems:
-random lockups
-disconnection (workaround rmmod && insmod hid-multitouch)
-the physical button (the whole touchpad) is not debounced, if you click once it does multiple clicks (workaround: use tap to click)

False Acused Problems:
-non-natural 2 finger scrolling works after reboot

please tell me if i shall test other things on my GL703GE...
Comment 75 Andy Shevchenko 2018-07-26 19:50:04 UTC
(In reply to Marc Landolt from comment #74)

> please tell me if i shall test other things on my GL703GE...

Marc, this bug is solely about GPIO issue. As Mika stated in comment #40, please create another one, or find if it's already created against HID subsystem.

Check what @jamir has, it perhaps similar to what you are esperiencing.
Comment 76 Marc Landolt 2018-07-26 23:04:15 UTC
ok, I did not find jamir's but so I opened one here:

https://bugzilla.kernel.org/show_bug.cgi?id=200663

thank you for your help :)
Comment 77 gschram 2018-08-05 14:55:56 UTC
(In reply to Andy Shevchenko from comment #49)
> (In reply to jamir from comment #48)
> > Created attachment 277507 [details]
> > Patch file used to test.
> > 
> > I am attaching the patch file I used to test.
> 
> Thanks for your patience! Now it's clear.
> 
> The translation patch has been sent to upstream today (we expect maintainer
> take it soon). The ACPI hack needs to be thought about a bit longer. We are
> waiting for some elaboration internally from other team.

This patch also fixes the touchscreen (and pen) and touchpad (only works after a hibernation) on the newly released hp zbook studio x360
Comment 78 Simon Detheridge 2018-08-08 23:01:23 UTC
I have an almost-identical problem with a Tong Fang GK5CN5Z laptop (branded as a PC Specialist Recoil II)

The symptoms appear very similar, but using the patches here the touchpad still does not work, although the error message changes.

I got a very similar "cannonlake-pinctrl" "pin x cannot be used as IRQ" message. I installed 4.18_rc8 and applied the patches here, but I now get a different error and the device still does not show up.

I see:
[    6.813578] usbhid 1-6:1.0: couldn't find an input interrupt endpoint
and
[   20.468857] i2c_hid i2c-UNIW0001:00: failed to reset device.
...
[   39.741876] i2c_hid i2c-UNIW0001:00: can't add hid device: -61

Not sure what further information is required, but I'll attach the full dmesg output.
Comment 79 Simon Detheridge 2018-08-08 23:02:17 UTC
Created attachment 277765 [details]
post-patch dmesg output for GK5CN5Z
Comment 80 Mika Westerberg 2018-08-09 08:35:50 UTC
To me this looks like a different issue (HID reset does not get through). Can you attach /proc/interrupts and /sys/kernel/debug/gpio here just that we can check whether it is related to GPIO at all?
Comment 81 Simon Detheridge 2018-08-09 09:33:11 UTC
OK, I shall add these. I'll also add the dmesg from before the patch for reference... The error line is:

[   15.386072] cannonlake-pinctrl INT3450:00: pin 208 cannot be used as IRQ
Comment 82 Simon Detheridge 2018-08-09 09:34:39 UTC
Created attachment 277783 [details]
pre-patch dmesg output for GK5CN5Z
Comment 83 Simon Detheridge 2018-08-09 09:35:23 UTC
Created attachment 277785 [details]
/proc/interrupts on GK5CN5Z
Comment 84 Simon Detheridge 2018-08-09 09:36:05 UTC
Created attachment 277787 [details]
/sys/kernel/debug/gpio on GK5CN5Z
Comment 85 Simon Detheridge 2018-08-09 12:30:19 UTC
If it helps, I tried using the laptop buttons to enable/disable the touchpad. Nothing happens, but dmesg says this:

[  254.890450] i801_smbus 0000:00:1f.4: BIOS is accessing SMBus registers
[  254.890459] i801_smbus 0000:00:1f.4: Driver SMBus register access inhibited
Comment 86 Andy Shevchenko 2018-08-09 16:14:32 UTC
(In reply to Simon Detheridge from comment #81)
> OK, I shall add these. I'll also add the dmesg from before the patch for
> reference... The error line is:
> 
> [   15.386072] cannonlake-pinctrl INT3450:00: pin 208 cannot be used as IRQ

Can you attach /sys/kernel/debug/pinctrl/INT3450:00/pins for *patched* version?

P.S. For now it looks like the GPIO problem gone, but please attach the file to make us sure. If it's the case, you would need to create another bug regarding to HID device communication issue.
Comment 87 Simon Detheridge 2018-08-09 16:29:00 UTC
Created attachment 277791 [details]
/sys/kernel/debug/pinctrl/INT3450:00/pins on GK5CN5Z post-patch

Sure, here's the output
Comment 88 Andy Shevchenko 2018-08-09 16:43:36 UTC
(In reply to Simon Detheridge from comment #87)
> Created attachment 277791 [details]
> /sys/kernel/debug/pinctrl/INT3450:00/pins on GK5CN5Z post-patch
> 
> Sure, here's the output

Thanks. I don't see any issues with GPIO now.
Comment 89 Simon Detheridge 2018-08-10 13:14:58 UTC
Raised as bug #200787 - if there's anything else I should add to that let me know, I'm not really sure what I'm doing with this.
Comment 90 Jon 2018-08-21 21:22:18 UTC
I'm facing the same exact problem as Simon with the Tong Fang GK5CN5Z model on Ubuntu 18.04. Is there any update concerning the fix? Thanks!
Comment 91 Simon Detheridge 2018-08-21 21:40:16 UTC
@Jon are you comfortable building your own kernel? It would be good to know if your experience is the same as mine in bug #200787 once the patches from this bug are applied.
Comment 92 Amey 2018-08-24 10:53:48 UTC
(In reply to Marc Landolt from comment #68)
> (In reply to Andy Shevchenko from comment #66)
> > Created attachment 277553 [details]
> > Fix community ordering for H variant
> > 
> > Another patch for Cannonlake PCH-H.
> 
> Yay, GREAT, Andy you're a Genius, the Touchpad is working :)
> 
> After Downloading Kernel 4.18.RC6, patching with
> https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff and
> https://bugzilla.kernel.org/attachment.cgi?id=277553&action=diff it's
> working.
> 
> -Tap to click works
> -2 Finger scroll works (only Natural Scrolling, always on)
> -2 Finger right click works
> -left mouse button works
> -right mouse button does not work but with 2 finger click it works
> -Edge Scrolling does not work
> -it disconects from time to time (rmmod -r hid-multitouch && modprobe
> hid-multitouch helps)
> 
> shall I test other patches and do you still need the outputs from Comment 67
> (interrupts, iomem, ranges, pins?
> 
> With kind regards and many thanks so far
> Marc Landolt

For me on Asus FX504 laptop with ELAN1200 touchpad tap to click doesn't work.
Comment 93 Mika Westerberg 2018-08-24 11:17:21 UTC
If your touchpad works in general (the device can be used somehow) and does not fail with "GPIO can't be used as IRQ" error, it is most probably not related to this bug. Please file a separate bug about it.
Comment 94 Jon 2018-08-26 13:31:54 UTC
@Simon: Thanks for the info, you did lots of hard work. I had a look on the other ticket too. I've never compiled by own kernel, so I have not tried the patch. 

I'm a bit surprised to see that we need a separate ticket for "Razer Blade 15" and "Recoil II" given that both of them are actually "Tong Fang GK5CN5". I also don't undertand why the above patch "works" on Razer does not on Recoil. That's my understanding from your messages, can you confirm?

If you do find a patch that more-or-less works for Recoil, please give me a shout. I'll try to test it on my side too. I just want to avoid compiling my own kernel given that I have no idea what I'm doing without expecting any positive outcome from that. On the other hand, if you want someone else to confirm something on a similar system, I'm more than happy to do it. Just be descriptive of what you want me to do. (I know how to code but never hacked the kernel)
Comment 95 Jon 2018-08-26 13:35:08 UTC
Also FYI, Razer says they are working into bringing a Linux Driver for the touchpad here: https://insider.razer.com/index.php?threads/razer-blade-15-ubuntu-18-04-trackpad-not-working.35999/#post-447134

Not sure what's the progress with that and whether this will cover not only Razers but any Tong Fang GK5CN5 based laptop. I would love an update if anyone from Razer is on the thread. Cheers! :)
Comment 96 jamir 2018-08-26 14:17:48 UTC
Razer released a recently 1.05 BIOS update that fixes the touchpad problem.
Comment 97 jamir 2018-08-26 14:23:31 UTC
Created attachment 278089 [details]
dsdt_before_after

Adding DSDT for Razer Blade 15 2018 before and after the 1.05 update.
Comment 98 Vasilis Vryniotis 2018-08-26 23:21:27 UTC
I'm facing the same problem on a Recoil II which is a similar but not identical model to Razers' (both are based on TongFang models). 

@Simon: I also read your details on Bug #200787. The two problems seem related so I tried the patches listed here for the pinctrl module (did not recompile the entire kernel, just the module) but that did not work unfortunately. 

Shameless plug: I appreciate that debugging drivers is not the most pleasant coding exercise, so the hero who will solve the problem on the GK5CN5Z model can claim this bounty: https://www.bountysource.com/issues/62633122-touchpad-on-tong-fang-gk5cn5z It's not much but others are welcome to pitch in. :)
Comment 99 Amey 2018-09-02 14:49:26 UTC
@Mika Westerberg  Well that was a mistake on my part. I forgot to put 30-touchpad.conf for enabling tap to click. Hope the patch would improve a little to fix random disconnects and make it in mainline kernel.
Comment 100 Marc Landolt 2018-09-05 20:31:39 UTC
(In reply to Andy Shevchenko from comment #69)
> (In reply to Marc Landolt from comment #68)
> > (In reply to Andy Shevchenko from comment #66)
> > > Created attachment 277553 [details]
> > > Fix community ordering for H variant
> > > 
> > > Another patch for Cannonlake PCH-H.
> > 
> > Yay, GREAT, Andy you're a Genius, the Touchpad is working :)
> 
> Sorry it wasn't working from the day 1.
> 
> > shall I test other patches
> 
> Nothing to test for now. There are three problems in your case and one of
> them doesn't clear yet (in a sense of root cause). That's, we are discussing
> internally and will come up with workaround / solution later on.
> 
> > and do you still need the outputs from Comment 67
> > (interrupts, iomem, ranges, pins?
> 
> Yes, please.

helly Andy Shevchenko,

the patch you wrote for me does not work on Kernel 4.19-rc2 anymore, so the touchpad does not work in kernel 4.19-rc2 because i can not apply https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff since someone has changed something in pinctrl-intel.c, so the patch works only with 4.18-rc6. my question is, this fix did not went into mainline?

with kind regards
Marc Landolt
Comment 101 Andy Shevchenko 2018-09-05 22:03:49 UTC
(In reply to Marc Landolt from comment #100)

> the patch you wrote for me does not work on Kernel 4.19-rc2 anymore, so the
> touchpad does not work in kernel 4.19-rc2 because i can not apply
> https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff since
> someone has changed something in pinctrl-intel.c, so the patch works only
> with 4.18-rc6. my question is, this fix did not went into mainline?

To be clear, there are three patches, two of which are part of v4.19-rc1.
The only piece is missed in upstream is pin ownership check W/A, that is effectively is a middle of the attachment #277507 [details].
Comment 102 Marc Landolt 2018-09-05 23:33:12 UTC
Hello Andy

i added now lines 1016, 1021 and 1022 from https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff to the /drivers/pinctrl/intel/pinctrl-intel.c from kernel 4.19-rc2 and now the touchpad works again, i guess if (intel_pad_acpi_mode(pctrl, pin)) evaluates to false and then it returns and does not do the rest of the function. But I'm not a C Coder, i know very little about C or Kernel things.

I will now test the things you said in thread and tell you the results in the thread https://bugzilla.kernel.org/show_bug.cgi?id=200663#c6

with kind regards
Marc Landolt
Comment 103 Hieu Cao 2018-09-06 02:39:50 UTC
I'm Using Asus Fx504GD (Elan1200) should to apply these patch?
Someone suggest me this link, so i'm a little confuse.
Comment 104 Hieu Cao 2018-09-06 04:17:54 UTC
I patched and boot correctly but in xinput it's still doesn't recognized my touchpad, and also my mouse (Mouse worked well on preview kernel).
Comment 105 trave5 2018-09-13 13:07:33 UTC
any new about this bug? tongfang gk5cn6z
Comment 106 Simon Detheridge 2018-09-17 06:55:49 UTC
@Hieu Cao you could try the additional patch from Bug #200787 - if your touchpad is connected the same ways as mine then it could be the problem.

@trave5 yes, I managed to get it working, see above
Comment 107 Hieu Cao 2018-09-17 10:43:12 UTC
(In reply to Simon Detheridge from comment #106)
> @Hieu Cao you could try the additional patch from Bug #200787 - if your
> touchpad is connected the same ways as mine then it could be the problem.

I'm glad to hear this sound. Today I'll try to install a Linux again on my computer (I already remove it and replaced by windows). Does it work the same thing on virtual machine? Because I still not getting how to manage dual boot effectly.
Comment 108 Simon Detheridge 2018-09-17 12:05:16 UTC
@Hieu Cao - I don't know for sure that the patch will fix your problem in this case, I just figured it might be worth a shot. It may not be worth reformatting your computer for though.

You shouldn't need any of this stuff for Linux on a VM, as your hypervisor will be virtualising your mouse pointer anyway, so it won't be seeing the gpio directly.
Comment 109 Hieu Cao 2018-09-17 13:59:13 UTC
(In reply to Simon Detheridge from comment #108)
> @Hieu Cao - I don't know for sure that the patch will fix your problem in
> this case, I just figured it might be worth a shot. It may not be worth
> reformatting your computer for though.
> 
> You shouldn't need any of this stuff for Linux on a VM, as your hypervisor
> will be virtualising your mouse pointer anyway, so it won't be seeing the
> gpio directly.

Thank for your advice. I kinda love to use Arch and I3wm. It friendly but now I using the Windows it becomes harder for me, I can not do anything without mouse or touchpad. And the Cli on Windows it does not have a friendly command :(
I think I should waiting when this project is complete for a stable patch.
Comment 110 Marc Landolt 2018-09-17 22:33:20 UTC
(In reply to Hieu Cao from comment #103)
> I'm Using Asus Fx504GD (Elan1200) should to apply these patch?
> Someone suggest me this link, so i'm a little confuse.

Hello Hieu

i can not tell for Fx504GD, for GL703GE you need to add these 3 lines from https://bugzilla.kernel.org/show_bug.cgi?id=199911#c102 i mentioned, otherwise the touchpad does not work at all...

if the Fx504GD has the same hardware as GL703GE then you have at least a functioning touchpad except that it crashes sometimes and then you need to rmmod and insmod hid-multitouch that it works again...

Try to kindly ask Andy Shevchenko he helped me to make my touchpad working. He Patched a lot, but this 3 lines i mentioned went not to mainline and without this 3 lines my touchpad does not work

with kind regards
Marc Landolt
Comment 111 Hieu Cao 2018-09-18 04:12:14 UTC
(In reply to Marc Landolt from comment #110)
> (In reply to Hieu Cao from comment #103)
> > I'm Using Asus Fx504GD (Elan1200) should to apply these patch?
> > Someone suggest me this link, so i'm a little confuse.
> 
> Hello Hieu
> 
> i can not tell for Fx504GD, for GL703GE you need to add these 3 lines from
> https://bugzilla.kernel.org/show_bug.cgi?id=199911#c102 i mentioned,
> otherwise the touchpad does not work at all...
> 
> if the Fx504GD has the same hardware as GL703GE then you have at least a
> functioning touchpad except that it crashes sometimes and then you need to
> rmmod and insmod hid-multitouch that it works again...
> 
> Try to kindly ask Andy Shevchenko he helped me to make my touchpad working.
> He Patched a lot, but this 3 lines i mentioned went not to mainline and
> without this 3 lines my touchpad does not work
> 
> with kind regards
> Marc Landolt

I trying to install arch and patch it again, but now I got an error when try to patch it.
https://pastebin.com/1aRfSJy4
It look like the new kernel I download from kernel.org was add these patch.
What I need to do now?
Or these patch are not compatible with the newest kernel?
Comment 112 Hieu Cao 2018-09-18 04:22:09 UTC
Opps, my bad.
I copied wrong patch so right now the patch is applied well.
Comment 113 Hieu Cao 2018-09-18 04:29:10 UTC
After i patched 2 patch, And I search in the direction (/drivers/pinctrl/intel/pinctrl-intel.c) these patch there. What i need to do now?
Comment 114 Hieu Cao 2018-09-18 04:35:53 UTC
3 lines you said to add to the /drivers/pinctrl/intel/pinctrl-intel.c it already there.
Comment 115 Mika Westerberg 2018-09-18 10:31:46 UTC
You only need this workaround:

+#if 0
 	if (intel_pad_acpi_mode(pctrl, pin)) {
 		dev_warn(pctrl->dev, "pin %u cannot be used as IRQ\n", pin);
 		return -EPERM;
 	}
+#endif

if you see "pin x cannot be used as IRQ" in your dmesg. If there is no such message then the hack is not needed. I think someone in this bug mentioned that with new BIOS this particular issue went away so I'm assuming the new BIOS corrects the pin ownership from ACPI to driver.
Comment 116 Hieu Cao 2018-09-18 10:41:33 UTC
(In reply to Mika Westerberg from comment #115)
> You only need this workaround:
> 
> +#if 0
>       if (intel_pad_acpi_mode(pctrl, pin)) {
>               dev_warn(pctrl->dev, "pin %u cannot be used as IRQ\n", pin);
>               return -EPERM;
>       }
> +#endif
> 
> if you see "pin x cannot be used as IRQ" in your dmesg. If there is no such
> message then the hack is not needed. I think someone in this bug mentioned
> that with new BIOS this particular issue went away so I'm assuming the new
> BIOS corrects the pin ownership from ACPI to driver.

Sorry but I'm still confuse. Does I need to patch 2 patch obove or just add only those code to the kernel source?
Comment 117 Mika Westerberg 2018-09-18 10:45:53 UTC
When you run "dmesg" command and there is a line saying something like "pin x cannot be used as IRQ" then you need to do the above hack. Otherwise it is not needed. Hope this makes it more clear :)
Comment 118 Mika Westerberg 2018-09-18 10:48:47 UTC
The other two patches are already included in v4.19-rc1 so there is no need to re-apply them (assuming you are running v4.19-rcX).
Comment 119 Hieu Cao 2018-09-18 11:39:10 UTC
(In reply to Mika Westerberg from comment #118 #117)

I understood, thanks for your reply. I gonna try when I have time, and will update the result.
@Mika
Comment 120 Hieu Cao 2018-09-18 20:07:15 UTC
@Mika Westerberq
When I copied that hack above it look weird. Only that code have a + before #.
Should I delete it?
Comment 121 Bo 2018-09-18 20:42:57 UTC
Hi, I have a similar problem on HP Zbook Studio G5. I tried the two patches from comment 68 on 4.18.rc6. It did not solve my problem. As suggested, I opened a new report bug 201175.
Comment 122 Hieu Cao 2018-09-19 00:51:12 UTC
@Marc Landolt
I also tried 4 patch on your other topic and it still not detected my touch pad
@Mika Westerberg
I'm tried to patch 2 (on kernel 4.18.8) without your code hack. But when I run dmesg | grep IRQ it doesn't have any pin error. But in the original (current running kernel 4.18.8) without any patch. I saw the error you mentioned 
[hieuc@archlinux ~]$ dmesg | grep IRQ
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] NR_IRQS: 20736, nr_irqs: 2048, preallocated irqs: 16
[    0.003333] DMAR-IR: Enabled IRQ remapping in x2apic mode
[    0.619217] ACPI: PCI Interrupt Link [LNKA] (IRQs) *0
[    0.619268] ACPI: PCI Interrupt Link [LNKB] (IRQs) *1
[    0.619317] ACPI: PCI Interrupt Link [LNKC] (IRQs) *0
[    0.619365] ACPI: PCI Interrupt Link [LNKD] (IRQs) *0
[    0.619414] ACPI: PCI Interrupt Link [LNKE] (IRQs) *0
[    0.619462] ACPI: PCI Interrupt Link [LNKF] (IRQs) *0
[    0.619510] ACPI: PCI Interrupt Link [LNKG] (IRQs) *0
[    0.619558] ACPI: PCI Interrupt Link [LNKH] (IRQs) *0
[    0.644183] PCI: Using ACPI for IRQ routing
[    0.730824] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0, 0, 0, 0, 0
[    0.891547] pcieport 0000:00:1d.0: AER enabled with IRQ 122
[    0.997281] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    3.600805] cannonlake-pinctrl INT3450:00: pin 225 cannot be used as IRQ
[    3.602284] cannonlake-pinctrl INT3450:00: pin 225 cannot be used as IRQ
[    3.674377] r8169 0000:02:00.0 eth0: RTL8168h/8111h, 4c:ed:fb:2c:e0:82, XID 54100800, IRQ 137
Comment 123 Mika Westerberg 2018-09-19 08:21:52 UTC
Hi,

Yes, the '+' should be deleted.

Could you try v4.19-rcX instead of v4.18.8 because it should include the two patches already. Then if you still see the "cannot be used as IRQ" error, you should apply the hack patch (otherwise it is not needed).
Comment 124 Hieu Cao 2018-09-19 14:35:39 UTC
I think I know what is my problem. May I patched the new kernel without any config except the name local and also I didn't install an xf86-input-libinput package. So that why my custom kernel kinda weird, it takes 4-5 minutes to compile, it worked not properly. Yesterday I have read the wiki page, and I realized that I can use the current config to a custom kernel's config: `zcat /procs/config.gz > .config. Then I compile it took more than 30 minutes (I guess because I slept). So after school, I will try to apply my custom kernel again. I hope it will detected my touchpad driver. If it still not detected, I'll try the newest kernel along your advice. Thanks
Comment 125 Hieu Cao 2018-09-19 21:20:23 UTC
Opps! I tried both kernel but it can not boot into arch with error: device UUID, mount: /new_root can't find UUID
I also run this command on the default kernel (mkinitcpio -p linux then update-grub) but it still not working
https://ibb.co/hE4R9z
Comment 126 Hieu Cao 2018-09-20 00:37:43 UTC
OMG! After few weeks I fixed this.
Thanks @Mika Westerberg @Marc Landolt @Thank you who created the patch
My problem exactly I compiled kernel wrong way. To make it work properly I have to use the current kernel's config. Also thanks everyone here to give me the ideas to not give up.
Comment 127 Hieu Cao 2018-09-20 01:22:33 UTC
(In reply to Marc Landolt from comment #74)
> There are still some issues, I guess it are the same issues that are also on
> the GL503VS and maybe in a different part of the kernel (not sure):
> 
> Problems:
> -random lockups
> -disconnection (workaround rmmod && insmod hid-multitouch)
> -the physical button (the whole touchpad) is not debounced, if you click
> once it does multiple clicks (workaround: use tap to click)
> 
> False Acused Problems:
> -non-natural 2 finger scrolling works after reboot
> 
> please tell me if i shall test other things on my GL703GE...

Can you give me the detail of disconnection fix? (Where I add rmmod and insmod hid-multitouch
Comment 128 Marc Landolt 2018-09-20 01:48:11 UTC
(In reply to Hieu Cao from comment #127)
> (In reply to Marc Landolt from comment #74)
> > There are still some issues, I guess it are the same issues that are also
> on
> > the GL503VS and maybe in a different part of the kernel (not sure):
> > 
> > Problems:
> > -random lockups
> > -disconnection (workaround rmmod && insmod hid-multitouch)
> > -the physical button (the whole touchpad) is not debounced, if you click
> > once it does multiple clicks (workaround: use tap to click)
> > 
> > False Acused Problems:
> > -non-natural 2 finger scrolling works after reboot
> > 
> > please tell me if i shall test other things on my GL703GE...
> 
> Can you give me the detail of disconnection fix? (Where I add rmmod and
> insmod hid-multitouch

its just a workaround

if you do a rmmod hid-multitouch && modprobe hid-multitouch then it starts working again, this problem is not fixed yet, i opened the following thread for this problem: https://bugzilla.kernel.org/show_bug.cgi?id=200663
Comment 129 Simon Detheridge 2018-09-20 13:05:25 UTC
I'm not sure if this is better commented here or bug #200787...

With 4.19_rc4, plus my patch to fix the gpp-e pin numbers, I'm still getting:

cannonlake-pinctrl INT3450:00: pin 210 cannot be used as IRQ

@Mika Westerberg mentioned a new BIOS, but my manufacturer doesn't currently have a BIOS update available, so I currently still need the hack.

I wonder if there's another less hacky solution to this, given that I know pin 210 *can* be used as an IRQ, and I suspect that there will be a number of devices in the wild which don't have an updated BIOS that fixes the ACPI issue?
Comment 130 Vasilis Vryniotis 2018-09-20 13:26:48 UTC
Just wanted to echo Simon's point on this. 

Applying the fixes of this ticket + Simon's pin patch gets the touchpad working. BIOS update is not currently available, let alone that most manufacturers don't have Linux users in mind...

I would love to see a proper fix for that in the Kernel because compiling a custom kernel is quite difficult for the average user. I couldn't have done it myself without the help of Simon.
Comment 131 Mika Westerberg 2018-09-20 13:35:23 UTC
Yes, we are working on it. Sorry that it takes so long but we need to get the right people in Intel involved to confirm whether the assertion in the driver is correct or not. Once we know that we can decide what is the proper fix.
Comment 132 Simon Detheridge 2018-09-20 15:43:24 UTC
marvellous :)
Comment 133 Hieu Cao 2018-09-21 00:50:38 UTC
(In reply to Marc Landolt from comment #128)
> (In reply to Hieu Cao from comment #127)
> > (In reply to Marc Landolt from comment #74)
> > > There are still some issues, I guess it are the same issues that are also
> > on
> > > the GL503VS and maybe in a different part of the kernel (not sure):
> > > 
> > > Problems:
> > > -random lockups
> > > -disconnection (workaround rmmod && insmod hid-multitouch)
> > > -the physical button (the whole touchpad) is not debounced, if you click
> > > once it does multiple clicks (workaround: use tap to click)
> > > 
> > > False Acused Problems:
> > > -non-natural 2 finger scrolling works after reboot
> > > 
> > > please tell me if i shall test other things on my GL703GE...
> > 
> > Can you give me the detail of disconnection fix? (Where I add rmmod and
> > insmod hid-multitouch
> 
> its just a workaround
> 
> if you do a rmmod hid-multitouch && modprobe hid-multitouch then it starts
> working again, this problem is not fixed yet, i opened the following thread
> for this problem: https://bugzilla.kernel.org/show_bug.cgi?id=200663

Thanks, this workaround is worked for me.
Comment 134 Mika Westerberg 2018-09-21 09:36:10 UTC
Created attachment 278693 [details]
Fix CNL-H HOSTSW_OWN offset

Simon et al. Could you try the attached patch and see if the "pin X cannot be used as IRQ" problem goes away?
Comment 135 Benjamin Tissoires 2018-09-24 11:06:24 UTC
Created attachment 278737 [details]
pinctrl-intel-Fix-pin-translation-when-requesting-IR.patch

Hi Mika,

I can confirm that your latest patch in comment #134 enables the touchpad of the HP Zbook mWS x360 that was buggy before. However, after applying the changes in the 'fixes' branch of the pinctrl tree, I realized that when requesting the IRQ, we are making twice the transposition from hwirq to pin.

I wrote a patch (attached) that fixes it, and I'd like to get your feedback before submitting it too.

With v4.19-rc4, the 2 patches that are on 'fixes' on pinctrl, and this one, the HP zbook I have here finally have both touchpad and touchscreen working without warnings in the dmesg.

(for references, the hwirq of the touchscreen is 77 that gets translatesd to 64, and the hwirq of the touchpad was around 250 and gets translated to 205 IIRC)
Comment 136 Mika Westerberg 2018-09-24 12:00:43 UTC
Hi Benjamin,

Hmm I don't see where we could do the translation twice. i2c-hid calls directly to irqchip so it should be using the non-translated numbers which then get translated in intel_gpio_irq_reqres() and the like to the appropriate pin numbers. Maybe I'm missing something.

Do you have possibility to add some debugging to the driver so that it prints out all the numbers (GPIO offset, hwirq and pin number)?

Also what is the error you are seeing after applying the last patch?

Thanks!
Comment 137 Mika Westerberg 2018-09-24 12:15:26 UTC
Actually you are right. The commit 55aedef50d4d810670916d9fce4a40d5da2079e7 ("pinctrl: intel: Do pin translation when lock IRQ") was added because gpiolib core calls ->get_direction() and that did not handle the translation properly. After the commit  96147db1e1dff83679e71ac92193cbcab761a14c ("pinctrl: intel: Do pin translation in other GPIO operations as well") we do translation so the previous commit is not needed and in fact it should not operate on pins in the first place (only with the GPIO numbers).

So I think the right fix for the issue you are seeing now is to revert 55aedef50d4d810670916d9fce4a40d5da2079e7 (basically your patch but also do the same for intel_gpio_irq_relres()).
Comment 138 Benjamin Tissoires 2018-09-24 12:15:34 UTC
Created attachment 278739 [details]
dmesg on th HP zBook x360, withoutgpio translation fixes

> Hmm I don't see where we could do the translation twice. i2c-hid calls
> directly to irqchip so it should be using the non-translated numbers which
> then get translated in intel_gpio_irq_reqres() and the like to the
> appropriate pin
numbers. Maybe I'm missing something.

I have put the backtrace in the attached dmesg:
- i2c_hid_probe()
- request_threaded_irq()
- intel_gpio_irq_reqres() -> translation from hwirq 77 to 64
- gpiochip_lock_as_irq()
- gpiod_get_direction() -> translation from hwirq 64 to 51
 -> failure to get direction:

[   11.360372] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: cannot get GPIO direction

> Do you have possibility to add some debugging to the driver so that it prints
out all the numbers (GPIO offset, hwirq and pin number)?

sure. The attached dmesg has the following diff:
---
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index ec8dafc..c08d464 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -783,6 +783,12 @@ static int intel_gpio_to_pin(struct intel_pinctrl *pctrl, unsigned offset,
                                        *community = comm;
                                if (padgrp)
                                        *padgrp = pgrp;
+                                       
+                               pr_err("%s: converting offset %d to %d",
+                                               __func__, offset, pin);
+                               
+                               if (offset == 64 || offset == 205)
+                                       dump_stack();
 
                                return pin;
                        }
---

> Also what is the error you are seeing after applying the last patch?

[   11.360372] gpio gpiochip0: (INT3450:00): gpiochip_lock_as_irq: cannot get GPIO direction
[   11.360446] cannonlake-pinctrl INT3450:00: unable to lock HW IRQ 64 for IRQ
[   11.360508] genirq: Failed to request resources for WCOM48A0:00 (irq 203) on irqchip intel-gpio
[   11.360661] i2c_hid i2c-WCOM48A0:00: Could not register for WCOM48A0:00 interrupt, irq = 203, ret = -22
[   11.363790] i2c_hid: probe of i2c-WCOM48A0:00 failed with error -22


Note that this only occurs for the touchscreen. The touchpad works fine, but if you look carefully at the logs, you'll see that the get_direction() gets called with pin 168 instead of 205 (with hwirq being 258).

So I guess here the touchpad works by luck because pin 168 is an actual GPIO while 51 is not.
Comment 139 Benjamin Tissoires 2018-09-24 12:30:59 UTC
(In reply to Mika Westerberg from comment #137)
> Actually you are right. The commit 55aedef50d4d810670916d9fce4a40d5da2079e7
> ("pinctrl: intel: Do pin translation when lock IRQ") was added because
> gpiolib core calls ->get_direction() and that did not handle the translation
> properly. After the commit  96147db1e1dff83679e71ac92193cbcab761a14c
> ("pinctrl: intel: Do pin translation in other GPIO operations as well") we
> do translation so the previous commit is not needed and in fact it should
> not operate on pins in the first place (only with the GPIO numbers).

I should have spotted that I was altering the behavior of this patch, indeed.

> 
> So I think the right fix for the issue you are seeing now is to revert
> 55aedef50d4d810670916d9fce4a40d5da2079e7 (basically your patch but also do
> the same for intel_gpio_irq_relres()).

Just tested and I can confirm that reverting 55aedef50, adding your "pinctrl: intel: Do pin translation in other GPIO operations as well" and the patch in comment #134 works great on the HP.
Comment 140 Mika Westerberg 2018-09-24 12:39:07 UTC
Thanks for checking! Do you want to submit the revert or should I?
Comment 141 Benjamin Tissoires 2018-09-24 12:55:33 UTC
(In reply to Mika Westerberg from comment #140)
> Thanks for checking! Do you want to submit the revert or should I?

Please do. I think it'll get faster this way. You can add my reported-and-tested-by on it (or anything similar that helps the process).
Comment 142 Mika Westerberg 2018-09-24 14:37:15 UTC
OK, just sent them out with you Cc'd.
Comment 143 Bo 2018-09-24 18:52:19 UTC
(In reply to Benjamin Tissoires from comment #141)
> (In reply to Mika Westerberg from comment #140)
> > Thanks for checking! Do you want to submit the revert or should I?
> 
> Please do. I think it'll get faster this way. You can add my
> reported-and-tested-by on it (or anything similar that helps the process).

Hi Benjamin,

Can i ask which patch you apply to which kernel to get the HP 360 touchpad working? is it from comment #134 or #135 or both ? and 4.19.rc?

I want to give a try on my zbook studio G5, thank you
Comment 144 Benjamin Tissoires 2018-09-24 19:04:16 UTC
(In reply to Bo from comment #143)
> Can i ask which patch you apply to which kernel to get the HP 360 touchpad
> working? is it from comment #134 or #135 or both ? and 4.19.rc?

I have:
- v4.19-rc4
- 8e2aac333785f91ff74e219a1e78e6bdc1ef2c41 ("pinctrl: cannonlake: Fix gpio base for GPP-E")
- 96147db1e1dff83679e71ac92193cbcab761a14c ("pinctrl: intel: Do pin translation in other GPIO operations as well")
- the 2 patches from https://patchwork.ozlabs.org/project/linux-gpio/list/?series=67208

8e2aac33378 and 96147db1e1dff are in v4.19-rc5, so you basically only need the 2 patches from Mika that has been sent today.

> I want to give a try on my zbook studio G5, thank you

Cool, please report, I am also interested in the results.
Comment 145 Mika Westerberg 2018-09-25 07:47:43 UTC
Created attachment 278751 [details]
pinctrl: cannonlake: Fix HOSTSW_OWN register offset of H  variant
Comment 146 Mika Westerberg 2018-09-25 07:48:19 UTC
Created attachment 278753 [details]
Revert "pinctrl: intel: Do pin translation when lock IRQ"
Comment 147 Mika Westerberg 2018-09-25 07:48:51 UTC
Attached the two patches that should be applied on top of v4.19-rc5.
Comment 148 Bo 2018-09-25 17:04:46 UTC
Hi Benjamin and Mika,

Thanks for the information. I compiled 4.19-rc5 with the two patches. Unfortunately my touchpad is still not responding upon boot. I have a similar problem as Comment 77, namely the touchpad only works after a hibernation. i attach the dmesg
Comment 149 Bo 2018-09-25 17:05:39 UTC
Created attachment 278755 [details]
dmesg_hp_zbook_studio_g5
Comment 150 Benjamin Tissoires 2018-10-01 20:04:56 UTC
Bo, the 2 patches are now in v4.19-rc6.
According to your dmesg, you have the same pin number that I have on the x360. I am a little bit worried that it doesn't work for you.

Could you try booting a vanilla v4.19-rc6 and report if your touchpad is still failing?
Comment 151 Bo 2018-10-03 16:39:26 UTC
(In reply to Benjamin Tissoires from comment #150)
> Bo, the 2 patches are now in v4.19-rc6.
> According to your dmesg, you have the same pin number that I have on the
> x360. I am a little bit worried that it doesn't work for you.
> 
> Could you try booting a vanilla v4.19-rc6 and report if your touchpad is
> still failing?

Hi Benjamin,
I was on vacation and the laptop is no longer at my hand. Sorry I cannot test at this moment. Will report as long as i get the laptop back, which might take some time. thanks for the help.
Comment 152 janus.reith 2018-10-18 17:24:07 UTC
I am also trying to get the touchscreen working on my zBook x360.
The touchpad worked ootb with kernel 4.18.12, but I can't get the touchscreen to work and dont know where to get started.

On all kernel versions I tried I ran xinput --list and xinput test while using the touchscreen, without success.

Beside 4.18.12 (which shipped with Fedora 29 Beta) i tried the latest 4.19.0-0.rc8 unmodified kernel, and I tried compiling the latest stable 4.18.14 with the patch "pinctrl-intel-translation-fix.patch" that is attached on this bug, as Benjamin Tissoires and gschramm pointed out that this works.

Nothing of this seemed to have any effect, could someone give me a hint?

- It seems like some of these patches are obsolete, which of them would still be necessary on 4.19.0-0.rc8 ? Or, which kernel version with which patches applied can be confirmed to work to make the kernel recognize the touchscreen?

- Where else can I get started with debugging beside running xinput to see what fails, or if the touchscreen is recognized? Are there other relevant os/userspace
factors beside the kernel that I need to take into account?

I'd appreciate any help!
Comment 153 janus.reith 2018-10-18 19:17:28 UTC
Accordingly to comments 144-147 I compiled the kernel from v4.19-rc5 branch and applied the two patches that were attached by Mika 2018-09-25.

Contrary to what Bo posted in 148, my Touchpad still works as it used to do with the other kernels(except some 4.15 kernel that shipped with a latest ubuntu live stick I tried).

Touchscreen still doesn't work.
Comment 154 Mika Westerberg 2018-10-19 08:11:05 UTC
Hi Janus,

Do you still see the message "GPIO can't be used as IRQ" when you boot the system? If not, it may be another issue and in that case I suggest you to file a bug against input subsystem/HID instead.
Comment 155 janus.reith 2018-10-19 11:00:35 UTC
dmesg | grep -i "GPIO" does not return anything, neither does dmesg --level=err
I guess my issue is not directly related then.
Comment 156 Benjamin Tissoires 2018-10-19 12:00:39 UTC
Janus, IIRC, lat time I checked, CONFIG_PINCTRL_CANNONLAKE was not set in the default configuration of Fedora kernels. Can you double check?

If CONFIG_PINCTRL_CANNONLAKE is not set, the device will not show up at all in the dmesg.
Comment 157 Hans de Goede 2018-10-19 13:33:59 UTC
(In reply to Benjamin Tissoires from comment #156)
> Janus, IIRC, lat time I checked, CONFIG_PINCTRL_CANNONLAKE was not set in
> the default configuration of Fedora kernels. Can you double check?
> 
> If CONFIG_PINCTRL_CANNONLAKE is not set, the device will not show up at all
> in the dmesg.

This sounds like something which we need to fix in the Fedora kernels. Benjamin, can you ask the Fedora kernel team to enable this ?
Comment 158 janus.reith 2018-10-19 13:47:50 UTC
@Benjamin, That seems to be right, the config file includes the comment "# CONFIG_PINCTRL_CANNONLAKE is not set".

This is also the case for their latest 4.19-0-0.rc8 vanilla kernel they provide in the repos.

When compiling myself I took over that configuration. Will enable it and give feedback after compilation finished!

(Hope I'm not going beyond the scope of this bug too far)
Comment 159 Benjamin Tissoires 2018-10-19 13:59:37 UTC
(In reply to Hans de Goede from comment #157)
> This sounds like something which we need to fix in the Fedora kernels.
> Benjamin, can you ask the Fedora kernel team to enable this ?

done: https://bugzilla.redhat.com/show_bug.cgi?id=1641057
I'll ping Laura if she doesn't take it in the next few days.

(In reply to janus.reith from comment #158)
> (Hope I'm not going beyond the scope of this bug too far)

No worries, it's better to understand why the fix is not working for you, and hopefully, the problem is just in the config file.
Comment 160 janus.reith 2018-10-19 14:43:06 UTC
Touchreen works now!

I built the kernel using the same setup I tried before, v4.19-rc5 with the two patches, now with CONFIG_PINCTRL_CANNONLAKE enabled.

I might be wrong, but it seems like the touchpad cursor speed seems to be faster? It already worked before, including multitouch gestures.

Just to clarify: If I compile the latest 4.19-0-0.rc8, will I still need the two patches?
Comment 161 Benjamin Tissoires 2018-10-19 14:57:56 UTC
(In reply to janus.reith from comment #160)
> I might be wrong, but it seems like the touchpad cursor speed seems to be
> faster? It already worked before, including multitouch gestures.

That's possible. Haven't paid much attention to this as the test setup I have is not my primary machine.

> 
> Just to clarify: If I compile the latest 4.19-0-0.rc8, will I still need the
> two patches?

IIRC, you should be good with a vanilla 4.19-rc8, yes. So no need for extra patches.
Comment 162 gschram 2018-10-19 15:07:11 UTC
I have compiled the 4.19-rc8 kernel today (using the mainline kernel package in Arch User Repository) on my HP ZBOOK G5 x360. And I can confirm the touchpad works way smoother (faster) now. This might be because libinput is now recognizing it, but I haven't been able to confirm this yet.
I didn't need any patches, so the touchscreen, pen and touchpad now work out of the box.

The only issue I still have is that GDM seems to have a problem starting with the new kernel (keep having a blinking cursor till I press the power button and then it goes to sleep, after sleep GDM works fine.

When I replaced GDM with Lightdm everything worked fine without going to sleep first.
Comment 163 Bo 2018-10-30 21:32:05 UTC
Hello,

Touchpad on my HP Zbook Studio G5 works great under the new 4.19 stable release. Thanks for the effort.
Comment 164 Ultron 2018-11-02 14:58:59 UTC
(In reply to Marc Landolt from comment #68)
> (In reply to Andy Shevchenko from comment #66)
> > Created attachment 277553 [details]
> > Fix community ordering for H variant
> > 
> > Another patch for Cannonlake PCH-H.
> 
> Yay, GREAT, Andy you're a Genius, the Touchpad is working :)
> 
> After Downloading Kernel 4.18.RC6, patching with
> https://bugzilla.kernel.org/attachment.cgi?id=277507&action=diff and
> https://bugzilla.kernel.org/attachment.cgi?id=277553&action=diff it's
> working.
> 
> -Tap to click works
> -2 Finger scroll works (only Natural Scrolling, always on)
> -2 Finger right click works
> -left mouse button works
> -right mouse button does not work but with 2 finger click it works
> -Edge Scrolling does not work
> -it disconects from time to time (rmmod -r hid-multitouch && modprobe
> hid-multitouch helps)
> 
> shall I test other patches and do you still need the outputs from Comment 67
> (interrupts, iomem, ranges, pins?
> 
> With kind regards and many thanks so far
> Marc Landolt

Thanks @Marc!

The same solution worked for GL503-GE ;-)

Cheers!
Comment 165 Hieu Cao 2018-11-11 05:32:49 UTC
Hi everyone.
Any news here, does the the disconnecting randomly has been fix?
Comment 166 Marc Landolt 2018-11-11 12:43:47 UTC
(In reply to Hieu Cao from comment #165)
> Hi everyone.
> Any news here, does the the disconnecting randomly has been fix?

Hello Hieu Cao

on my GL703GE it's not randomly but when you put the palm or 5 or more fingers on it.

i opened another bug but not assigned yet and i did not hear from any solution so far: https://bugzilla.kernel.org/show_bug.cgi?id=200663

With kind regards
Marc
Comment 167 Hieu Cao 2018-11-11 13:54:31 UTC
Thanks Marc Landolt
I'll following that bug, I hope it will be fix in the future.
Comment 168 Andy Shevchenko 2019-01-05 13:49:27 UTC
This bug has been fixed in v4.20.
Comment 169 Hieu Cao 2019-01-06 16:25:06 UTC
It worked on v4.20 automatically. Few days ago, but I also uninstalled it either. Because the annoyning of disconnecting. I wonder if it fixed the disconnecting? I just want to make sure that to reinstall linux again.

(In reply to Andy Shevchenko from comment #168)
> This bug has been fixed in v4.20.
Does it fix the disconnecting problem?
Comment 170 Marc Landolt 2019-01-06 22:19:22 UTC
(In reply to Hieu Cao from comment #169)
> It worked on v4.20 automatically. Few days ago, but I also uninstalled it
> either. Because the annoyning of disconnecting. I wonder if it fixed the
> disconnecting? I just want to make sure that to reinstall linux again.
> 
> (In reply to Andy Shevchenko from comment #168)
> > This bug has been fixed in v4.20.
> Does it fix the disconnecting problem?

in my case (Asus GL703GE) it does not. Disconnection Problem persists, but you can take now a 4.20 Kernal without patch and the Touchpad will work except if you put 5 Fingers or the Palm on it (on GL703GE)

with kind regards
Marc Landolt
Comment 171 Bo 2019-09-10 08:40:38 UTC
This problem is not completely resolved: touchpad is not full functional after waking from suspend. This has been confirmed by multiple users as reported in #201175.