Hi,
I wanted to request some testing from folks with 13 or 16 AMD and this patch:
https://lore.kernel.org/linux-gpio/20240519124109.1523-1-mario.limonciello@amd.com/T/#u
It changes the configuration so that only one CPU wakes up when processing a touchpad interrupt. I don’t expect any idle power consumption changes but I do anticipate it should help “average” use.
I also don’t expect any negative side effects but I would love to hear any feedback.
Thanks!
Can this patch be applied to kernel 6.8 “Ubuntu edition” (as found here)? Is such a test useful for you?
Yeah it can probably apply back as far as kernel 6.1. And yes with how self contained it is tests with anything are useful data points.
For Tumbleweeders: I’m trying to get some support here on how to apply this patch:
Right now it seems that the pinctrl_amd module is not loaded on my system. If you are in the same situation feel free to follow that thread 
I had a go at testing this, but didn’t see any improvement.
I applied the patch via NixOS’ boot.kernelPatches option to 6.9.1, rebooted into GNOME, enabled aeroplane mode, ran powerstat in a shell and compared leaving the system idle vs drawing circles with the touchpad. As you can see in run data, IRQ/s ramped up and consumed ~2W in both baseline and with the patch applied.
Tailing /proc/interrupts, I see activity on AMDI0010:03, pinctrl_amd and PIXA3854:00. grep -E 'PIXA|AMDI0010:03|pinctrl|CPU' /proc/interrupts before and after the patch shows activity’s still split over core 3 and 5.
@Mario_Limonciello, could you verify this?
Thanks for the testing! That’s really interesting that you ended up with the interrupt affinity matching the same cores already. I’m not sure why that happened, but they’re definitely nominally different for me. Is this a 13 or 16?
As for the power improvements, I think that the sample rate might be too long when it’s done in the OS. But you can’t really make it shorter because then you compromise the test by waking up to sample. It might be better to use an external dongle/probe and no battery if at all possible.
I’ll let this thread know when I spin a new version.
You know, looking at your logs, I’m wondering if I really made a logic mistake - it should be the AMDI0010:03 should align the affinity as well. Could you manually change the affinity using echo $CPU_NUM > /proc/irq/$INT_NUM/smp_affinity and see if that changes anything?
It still is a challenging move to glue these together in the kernel though.
I ran echo 20 > /proc/irq/6/smp_affinity to co-locate AMDI0010:03 with the others and observed all events correctly handled by CPU5. However, I didn’t see any power improvements (still ramped up to ~2W). I’m testing on a Framework 13 7640U.
Thanks for your continued work improving the platform btw!
Ok. From tomorrow I’ll be running the patched kernel. I don’t know how to have measure power consumption for a reliable A-B test in this case, but I will eventually report on any side effect. For now I don’t see anything noticeable working worse.
One last question: looking at the linked bug there is another patch, should I have applied that one as well?
P.S. This has been my first kernel recompile on my framework, I still have to figure out secure boot signing but testing with SB disabled everything works fine.
No that’s an alternative. Based on the above testing so far by @tlvince I don’t expect any notable differences, but would love to hear if you do find so!
Note: I’m also seeing both pinctrl_amd and PIXA3854:00 pinned to the same core consistently (without the patch). Same as @tlvince’s before.
Framework 13 7840U. But I’m using a touchpad back from the 11th gen in case that matters.