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


On 1/5/22 15:23, Jarkko Nikula wrote:
> 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?

Weird, I wonder what the root cause of this is...

> 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-10 15:44 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
2022-01-10 15:44                   ` Hans de Goede [this message]
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.