Impossible to use GPIO interrupts for multiple I2C devices

[ben9923]

On some machines, when multiple devices are using GPIO interrupts as their event source, only one of them is actually usable. Others are dead.
When putting either/both in polling mode, both of them work properly.

Are we clearing one pin's interrupt status while handling the other one?

Request for community: Anyone experiencing such issue - Please attach a full troubleshooting archive + clear description.
If you have multiple devices using GPIO and all of them work at the same time, please report it works.
We only have untracked Gitter reports, a fix requires proper tracking and debug information.

[zhen-zen]

iirc I have both my I2C devices (I2C0->TPD0, I2C1->TPL1, I2C3->SHUB) set to GPIO interrupt before and at least the previous two work simultaneously. (Currently don't have time to get the sensor hub working)

EDIT: just re-enabled a patch that replaces all SBFB, SBFI with SBFB, SBFG and all devices work.

Controller	Device	gpioIRQ	gpioPin
I2C0	TPD0	0x8	0x67
I2C1	TPL1	0x8	0x1b
I2C3	SHUB	0x8	0x3f

[ben9923]

@zhen-zen Thanks for the clarification! So it only happens on some machines.

@M69W Thanks for linking with the issue you opened.

[Goshin]

@ben9923 I just find a commit in my git stash Goshin/VoodooGPIO@5c7b5e3. It might be helpful for this issue but not tested for the multi-pin usage, in which I move enabling/disabling of device interrupts into registering/unregistering, so a pin will not interfere with others when the interrupts trigger simultaneously.

[ben9923]

@Goshin I'm not sure it would resolve the issue (I mean, why would they interfere in the first place?), but really do want someone with this issue to check out those changes.
It might cause interrupts being processed during sleep (Assuming some devices will send those), but I don't think we should worry about that.

[Goshin]

@ben9923 The interrupt needs to be temporarily disabled during the process of polling data from I2C. On Linux it is done by masking the corresponding pin but VoodooGPIO also disables the interrupt of the GPIO device, which I thought could also block interrupts for the other active pins. Indeed the effect should be minor because ideally it only happens when two devices are used simultaneously.
For the issue you mentioned above, can you see interrupts triggered by the "dead" device?

[M69W]

try to change another GPIO device pin to 1b?
#392 (comment)

[thefiredragon]

Would the question here, what changed above 2.4.4 which break interrupt mode for 2 devices.
Im on a dell xps 9500 with touchscreen and touchpad. Staying this release since I got it working, had no issues till yet.
Some people mean it would eat lot of battery power which I can not confirm.

[lollando21]

I have an HP laptop with 10th generation CPU (Comet Lake), with touchpad and touchscreen both on I2C. respectively:

• touchpad

  SYNA328B
  
pci8086,2e8
  

_SB.PCI0.I2C0.TPD0
• touch screen

  ELAN2514
  
pci8086,2e9
  

_SB.PCI0.I2C1.TPL1

both work correctly but NOT at the same time:
If I only use VoodooI2CHID.kext only the touchscreen works (10 touch and gestures), if I also add VoodooI2CELAN.kext the touchscreen stops working, BUT the touchpad works correctly (max 5 touch and gestures).


in both cases I had confirmation of the correct functioning of both devices through FingerMgmt, but, as I have already said, not at the same time

The DSDT is original (except for a small change for the mapping of the buttons for adjusting the brightness of the screen, in any case, I did some tests with the DSDT 100% clean and nothing has changed); I haven’t applied any modifications to the GPIO in the DSDT since the value of “IOInterruptSpecifiers” are respectively "10" and "11”.

The current config is:

• No SSDT-GPI0
• SSDT-XOSI and _OSI to XOSI patch applied

Kext order:

• VoodooGPIO
• VoodooI2CServices
• VoodooInput ***
• VoodooI2C
• VoodooI2CHID
• VoodooI2CELAN (in case)
  *** taken from the kext VoodooPS2Controller as it is more up to date, that of the kext VoodooI2C has been disabled to avoid conflicts (but also tested the original I2C one)

“Settings>Accessibility>Pointer Control>Ignore built-in trackpad when mouse or wireless trackpad is present” is unchecked

trackpad/mouse PlugIns of VoodooPS2 are disabled.

IOReg:
MacBook Pro.zip

dmesg ELAN2514 (while only touchscreen works):
dmesg ELAN2514.zip

dmesg SYNA328B (while trackpad only works):
dmesg SYNA328B.zip

DSDT:
DSDT.aml.zip

[ben9923]

Only happens on cases where the two pins are in the same padgroup?
It appears that first to register for interrupts is the one that works.
Might be related to the previous optimization made for per-pin handling, as it implies registration order = handling order, though unclear how it broke it for now.

[TomHeaven]

I meet a similar issue on Huawei Matebook X Pro 2020 laptop. The details are available at #509.
At current I'm using force polling mode and both of my touchpad and touchscreen works fine.

[TomHeaven]

Merely forcing polling mode may still meet the no response issue from the trackpad. In summary, there are three steps to fix the issue:

1. Force polling mode by adding boot argument -vi2c-force-polling using VodooI2C 2.7.0.
2. Boot to Windows and use device manager to uninstall the trackpad, scan PnP devices and update the driver locally. Of course, the step requires you have Windows installed.
3. Shutdown the laptop, unplug power cable, and wait for above 30 seconds.
   Now, start the laptop and the trackpad should work fine.