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

[Hans de Goede <hdegoede@xxxxxxxxxx>]

Hi,

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.

Ack.

Regards,

Hans