Fwd: [Framework Laptop] High power consumption when i2c hid touchpad is in use

From: Bagas Sanjaya
Date: Mon Nov 20 2023 - 21:04:04 EST


Hi,

I notice an interesting bug report on Bugzilla [1]. Quoting from it:

> On our 11th to 13th gen Framework Laptops, we see high power usage when the i2c-hid connected touchpad is in use. We suspect this bug also will impact other Intel systems using these type of touchpads.
>
> We would like to see if the kernel could group interrupts that service touchpads so that both the ACPI GPIO interrupt and designware i2c interrupt are bound to the same core to avoid waking two separate cores whenever the touchpad is in use to reduce power consumption. Or kernel maintainers may have a better idea to improve this.
>
> Background:
> We have found that when the touchpad is in use, the touchpad interaction with the CPU will follow the following sequence: 1. the touchpad will generate a GPIO interrupt to the CPU. The CPU will then perform a series of i2c reads using the i2c controller in master mode to retrieve an in report from the touchpad.
>
> The touchpad will generate GPIO interrupts at a rate of around 140 interrupts/second.
> The intel designware-i2c driver will generate interrupts at a rate of around 1000 interrupts / second.
>
> Intel premier support agents asked us to open a bug here to track this issue.
>
> Reproduction steps:
> 1. Boot to a gui environment and let the system idle, such as fedora desktop with no applications running.
> 2. Run a program like s-tui as root to measure the CPU / Psys power consumption.
> Observe the power consumption of the system for several seconds without touching the touchpad.
> 3. Touch the touchpad and move your finger around, note the system package power consumption will increase by about 2W. We measured the touchpad, and the touchpad will not cause a measurable increase in system power consumption. Additionally the s-tui results show the additional power consumption is coming from the CPU.
>
> I looked at this using Fedora, and it seems the gpio interrupt is pinned to one core, and the i2c interrupts are pinned to a separate core. This means every time the touchpad fires an interrupt, both a high performance and efficiency core cluster have to wake up to service the touchpad. And these are probably not even in the same cluster, so lots of cache evictions etc might be happening as both core clusters power on and off and caches are cleared and filled.
>
> What core type are TP interrupts handled by?
>
> The second thing was to find out what cores the interrupts were handled by:
>
> cat /proc/interrupts
>
> watch -n 1 "cat /proc/interrupts | grep designware"
> watch -n 1 "cat /proc/interrupts | grep PIXA"
>
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 CPU12 CPU13 CPU14 CPU15 CPU16 CPU17 CPU18 CPU19
> 43: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 43694516 0 0 0 0 IR-IO-APIC 43-fasteoi i2c_designware.2, idma64.2
> 135: 0 0 1711105 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 intel-gpio 3 PIXA3854:00
>
> And move the touchpad, you will see which core the touchpad interrupts are increasing on both.
> However the PIXA ACPI GPIO interrupt is pinned to a high performance core, but the i2c-designware interrupt is pinned to an efficiency core.
>
> Lets pin them both to the same core CPU2:
>
> # echo 00004 > /proc/irq/43/smp_affinity
> # echo 00004 > /proc/irq/135/smp_affinity # DOESNT WORK, IO error?
>
> Power consumption when using the touchpad seems to drop from about 7W to 5W! (Baseline is 4W)
>
>
> Background is here: https://community.frame.work/t/tracking-touchpad-interrupts-battery-usage-issues-idma64-2/13630/35

See Bugzilla for the full thread.

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218169

--
An old man doll... just what I always wanted! - Clara