Problem with high CPU usage caused by large number of interrupts

I’ve recently installed EOS on an ASUS Zenbook Flip UX360CA. Functionality wise everything works but I noticed the battery life is worse and the laptop runs hotter than it did with Windows. HTOP shows one of the CPU threads constantly runs around 35%, when the system should be idle. This is what’s causing the battery life and heat issues, as it’s stopping the CPU from clocking down like it should.

mpstat showed IRQ is what was spiking one of the CPU threads. Cat /proc/interrups shows this:

           CPU0       CPU1       CPU2       CPU3
   1:          0          0        153          0  IR-IO-APIC    1-edge      i8042
   8:          0          0          0          0  IR-IO-APIC    8-edge      rtc0
   9:          0         11          0          0  IR-IO-APIC    9-fasteoi   acpi
  16:          0    6622557          0          0  IR-IO-APIC   16-fasteoi   idma64.0, i2c_designware.0, i801_smbus
  17:          0          0          0          0  IR-IO-APIC   17-fasteoi   idma64.1, i2c_designware.1
  20:        123          0          0          0  IR-IO-APIC   20-fasteoi   intel_ish_ipc
  93:          0          0      99485          0  IR-IO-APIC   93-fasteoi   FTSC1000:00
 109:          0       3374          0          0  IR-IO-APIC  109-fasteoi   ELAN1200:00
 120:          0          0          0          0  DMAR-MSI    0-edge      dmar0
 121:          0          0          0          0  DMAR-MSI    1-edge      dmar1
 122:          0          0          0          0  IR-PCI-MSI 458752-edge      PCIe PME, aerdrv
 123:          0          0          0      15223  IR-PCI-MSI 376832-edge      ahci[0000:00:17.0]
 124:          0          0          0        233  IR-PCI-MSI 327680-edge      xhci_hcd
 125:          0          0          0         39  IR-PCI-MSI 360448-edge      mei_me
 126:      11795          0          0          0  IR-PCI-MSI 32768-edge      i915
 127:          0          0          0       1161  IR-PCI-MSI 524288-edge      iwlwifi
 128:        407          0          0          0  IR-PCI-MSI 514048-edge      snd_hda_intel:card0

You’ll see number 16 has a huge number of interrupts for idma64.0, i2c_designware.0, and i801_smbus. I saw online someone had a similar issue with the i801 module and they fixed it by adding " i2c-i801.disable_features=0x10" to their GRUB cmdline to disable interrupts for it. I tried it but it didn’t fix my issue, interrupts were still high. I also saw someone blacklisted the designware driver by adding “initcall_blacklist=dw_i2c_init_driver” to their GRUB cmdline. Doing this causes both the touchpad and the touchscreen to stop functioning, but the IRQ storm does stop when this is disabled so this certainly seems to be related to the touchpad.

My input devices show up as

I: Bus=0018 Vendor=04f3 Product=301a Version=0100
N: Name="ELAN1200:00 04F3:301A Touchpad"
P: Phys=i2c-ELAN1200:00
S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-ELAN1200:00/0018:04F3:301A.0004/input/input21
U: Uniq=
H: Handlers=event7 mouse2
B: PROP=5
B: EV=1b
B: KEY=e520 10000 0 0 0 0
B: ABS=2e0800000000003
B: MSC=20

I: Bus=0018 Vendor=2808 Product=5112 Version=0100
N: Name="FTSC1000:00 2808:5112"
P: Phys=i2c-FTSC1000:00
S: Sysfs=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-FTSC1000:00/0018:2808:5112.0005/input/input22
U: Uniq=
H: Handlers=event9 mouse3
B: PROP=2
B: EV=1b
B: KEY=400 0 0 0 0 0
B: ABS=3273800000000003
B: MSC=20

Pointer devices from xinput

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ ELAN1200:00 04F3:301A Mouse               id=12   [slave  pointer  (2)]
⎜   ↳ ELAN1200:00 04F3:301A Touchpad            id=13   [slave  pointer  (2)]
⎜   ↳ FTSC1000:00 2808:5112                     id=14   [slave  pointer  (2)]

Another odd thing about it is that it’s inconsistent. Majority of the time I have this IRQ problem with the high CPU usage, but there are times when it boots up and runs fine with normal CPU usage and no IRQ storm. When that happens it will run fine for that entire session, but if I reboot it will most likely have the problem when it comes back up, even with no updates or configuration changes. There’s no rhyme or reason to it that I can discern.

I see the same problem on live sessions run from USB, so it’s not something specific to my installation.

I’m not really sure where I go from here. I’m hoping someone more experienced with kernel modules might have some ideas.

Thanks for any help.