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

[Hans de Goede <hdegoede@xxxxxxxxxx>]

Hi Jarkko,

On 1/4/22 15:38, Jarkko Nikula wrote:
> Hi
> 
> On 1/4/22 12:48, Hans de Goede wrote:
>> So I've written another patch, which I believe is something which we will want
>> regardless of the question if we should mask interrupts at boot or not.
>>
>> I've attached this patch here. Jarkko, can you test a linux-next kernel with
>> just this patch added?
>>
>> This should still lead to the "interrupt on unused interrupt line %u" message
>> getting printed, but hopefully the system will actually boot despite this,
>> since the code path printing the msg now acks the interrupt.
>>
>> Thinking more about this I believe that this is likely the correct fix for
>> the caused regression, because the spurious IRQ was always there already.
>>
>> Fixing the spurious IRQ is still good to do but is a somewhat separate issue
>> really.
>>
> Unfortunately it doesn't fix:
> 
> [   13.060619] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
> [   13.068888] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
> [   13.077146] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
> [   13.085364] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
> ...
> 
> I did dev_err_ratelimited() conversion to the error print together with your patch and that allowed to boot.

Ok, thank you for testing all my different patches.

> 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.

Regards,

Hans