Re: pinctrl-cherryview regression in linux-next on preproduction Braswell

From: Jarkko Nikula <jarkko.nikula@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-gpio@vger.kernel.org,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andy@kernel.org>
Subject: Re: pinctrl-cherryview regression in linux-next on preproduction Braswell
Date: Wed, 5 Jan 2022 16:23:24 +0200	[thread overview]
Message-ID: <0c6900c2-656b-833f-5775-b76a852bc8eb@linux.intel.com> (raw)
In-Reply-To: <d04b5312-a38f-e7a7-f6cf-35320daade39@redhat.com>

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