Hi, we are enabling a new system, but the touchpad doesn't operate in I2C mode. Here's what we found. First, I also tried Rafael's linux-pm/acpi branch, same issue can be observed. After boot, the touchpad's _HID should be replaced with SYNA2393, but it remains XXXX0000, $ sudo ./acpidbg -b 'ex \_SB.PCI0.I2C0.TPD0._HID' Evaluating \_SB.PCI0.I2C0.TPD0._HID Evaluation of \_SB.PCI0.I2C0.TPD0._HID returned object 00000000b3d1c892, external buffer length 28 [String] Length 08 = "XXXX0000" Manually run its _INI method, $ sudo ./acpidbg -b 'ex \_SB.PCI0.I2C0.TPD0._INI' Evaluating \_SB.PCI0.I2C0.TPD0._INI Evaluation of \_SB.PCI0.I2C0.TPD0._INI returned object 000000007e7247be, external buffer length 18 [Integer] = 0000000000000000 Get its _HID again, $ sudo ./acpidbg -b 'ex \_SB.PCI0.I2C0.TPD0._HID' Evaluating \_SB.PCI0.I2C0.TPD0._HID Evaluation of \_SB.PCI0.I2C0.TPD0._HID returned object 000000007e7247be, external buffer length 28 [String] Length 08 = "SYNA2393" But its _STA still returns 0, but I guess it's a separate issue, $ sudo ./acpidbg -b 'ex \_SB.PCI0.I2C0.TPD0._STA' Evaluating \_SB.PCI0.I2C0.TPD0._STA Evaluation of \_SB.PCI0.I2C0.TPD0._STA returned object 000000007e7247be, external buffer length 18 [Integer] = 0000000000000000 Here's the _STA for it, Method (_STA, 0, NotSerialized) // _STA: Status { If (((TPDT != Zero) && (I2CN & One))) { Return (0x0F) } Return (Zero) } I can find TPDT but not I2CN, $ sudo ./acpidbg -b 'ex TPDT' Evaluating \TPDT Evaluation of \TPDT returned object 00000000622d7199, external buffer length 18 [Integer] = 0000000000000001 $ sudo ./acpidbg -b 'ex I2CN' Evaluating \I2CN Evaluation of \I2CN failed with status AE_NOT_FOUND Should ODM set it in the BIOS?
Created attachment 273705 [details] acpidump
Created attachment 273707 [details] dmesg
Hi Kai-Heng, Can you try this patch and see what happens? Also, when looking up I2CN, you should try doing this: 'ex _SB.PCI0.I2C1.I2CN' instead of 'ex I2CN'. It would be great if you could try executing the above acpidbg command with and without the patch.
Created attachment 273741 [details] MLC patch
So seems like SYNA2393 connects to both I2C0 and I2C1, here's the output: # ./acpidbg -b 'ex \_SB.PCI0.I2C0.I2CN' Evaluating \_SB.PCI0.I2C0.I2CN Evaluation of \_SB.PCI0.I2C0.I2CN returned object 000000006e2ebfb5, external buffer length 18 [Integer] = 0000000000000000 # ./acpidbg -b 'ex \_SB.PCI0.I2C1.I2CN' Evaluating \_SB.PCI0.I2C1.I2CN Evaluation of \_SB.PCI0.I2C1.I2CN returned object 000000006e2ebfb5, external buffer length 18 [Integer] = 0000000000000000 Aten applying the patch the hid-multitouch on i2c-hid works now, # ./acpidbg -b 'ex \_SB.PCI0.I2C0.I2CN' Evaluating \_SB.PCI0.I2C0.I2CN Evaluation of \_SB.PCI0.I2C0.I2CN returned object 00000000f2a7b2e5, external buffer length 18 [Integer] = 0000000000000002 # ./acpidbg -b 'ex \_SB.PCI0.I2C1.I2CN' Evaluating \_SB.PCI0.I2C1.I2CN Evaluation of \_SB.PCI0.I2C1.I2CN returned object 00000000f2a7b2e5, external buffer length 18 [Integer] = 0000000000000001 So looks like [1] from Lv Zheng didn't get merged by upstream? Is this change going to get merged in 4.16? [1] https://lkml.org/lkml/2016/6/20/190
Ok sounds like module level code is the issue. We have yet to merge this due to a few issues that are present the code executed by setting this flag. We are aiming for having patches by the end of the quarter. I can send out patches to you for testing once they are ready.
(In reply to Erik Schmauss from comment #6) > Ok sounds like module level code is the issue. We have yet to merge this due > to a few issues that are present the code executed by setting this flag. We > are aiming for having patches by the end of the quarter. Will it be in Rafael's linux-pm/acpi tree anytime soon? I can backport it to Ubuntu's tree, it doesn't need to be in mainline, but should be in some maintainer's tree. > I can send out patches to you for testing once they are ready. Sure, CC me when you send the patches.
(In reply to Kai-Heng Feng from comment #7) > (In reply to Erik Schmauss from comment #6) > > Ok sounds like module level code is the issue. We have yet to merge this > due > > to a few issues that are present the code executed by setting this flag. We > > are aiming for having patches by the end of the quarter. > Will it be in Rafael's linux-pm/acpi tree anytime soon? > I can backport it to Ubuntu's tree, it doesn't need to be in mainline, but > should be in some maintainer's tree. I think we will have a few people test this patch before it goes into Rafael's tree. We have a few people who have similar issues. I will let you know if we decide otherwise. > > > I can send out patches to you for testing once they are ready. > Sure, CC me when you send the patches.
Hi Kai-Heng, I would like to keep the Linux bugzilla organized so I will close this bug and mark it as moved. You can track the issue here: https://bugs.acpica.org/show_bug.cgi?id=963