All of
 help / color / mirror / Atom feed
From: Jarkko Nikula <>
To: Hans de Goede <>
	Mika Westerberg <>,
	Andy Shevchenko <>
Subject: Re: pinctrl-cherryview regression in linux-next on preproduction Braswell
Date: Wed, 5 Jan 2022 16:23:24 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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 

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.


  reply	other threads:[~2022-01-05 14:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-03  9:42 pinctrl-cherryview regression in linux-next on preproduction Braswell Jarkko Nikula
2022-01-03 10:42 ` Hans de Goede
2022-01-03 12:34   ` Jarkko Nikula
2022-01-03 16:06     ` Hans de Goede
2022-01-03 16:40     ` Hans de Goede
2022-01-04  9:43       ` Jarkko Nikula
2022-01-04 10:22         ` Hans de Goede
2022-01-04 10:48           ` Hans de Goede
2022-01-04 14:38             ` Jarkko Nikula
2022-01-04 14:47               ` Hans de Goede
2022-01-05 14:23                 ` Jarkko Nikula [this message]
2022-01-10 15:44                   ` Hans de Goede
2022-01-04 15:26           ` Mika Westerberg
2022-01-04 16:37             ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.