On 1/4/22 16:47, Hans de Goede wrote:
Hi Jarkko,
On 1/4/22 15:38, Jarkko Nikula wrote:
That gave me an idea to look at is there anything suspicious in "top" or /proc/interrupts (no and no) but powertop shows CPU 0 is over 90 % in C0 state and max frequency.
But comparing powertop on v5.16-rc8 it does look sometimes the same and sometimes CPU 0 is less in C0 (but still over 30 %). Hard to say is there difference but obviously v5.16-rc8 either is not good on this machine since CPU 0 and package seems to reach idle only 5 % or less.
Hmm, does this happen to with the "hack" patch to initially mask interrupts
triggered by all the interrupt-lines of the GPIO-controller ?
Ah upon reading your reply a second time I see you already checked
/proc/interrupts; and that you are also seeing this with 5.16-rc8.
So the load is likely not caused by the pinctrl issue and there also
is some other issue I guess...
For the high cpu-load issue it would be good to know if this is
also present on older kernels.
Sorry I mean cpu load is near idle according to top and no visible
interrupt flood in /proc/interrupts but powertop shows CPU 0 is mostly
in C0 or C1 state and doesn't idle or idles very near to 0 %. This is
from v5.16-rc8.
I think on this machine only MMC card detect is using the pincontrol. At
least pinctrl_cherryview module usage drops to zero and no users in
/sys/kernel/debug/gpio after unbinding all devices from
/sys/bus/platform/drivers/sdhci-acpi/.
MMC looks like to be well behaving since nothing changes after unbinding
it and card detect is this one "INT33FF:03: using interrupt line 0 for
pin 81".
However if I blacklist cherryview-pinctrl then CPU 0 and package will
reach deeper C states. Perhaps misconfigured pin etc by the firmware?
But since those issues were here before the regression and your fix
makes the machine booting again this case is solved by it.
Jarkko
