From: Hans de Goede <firstname.lastname@example.org>
To: Jarkko Nikula <email@example.com>
Mika Westerberg <firstname.lastname@example.org>,
Andy Shevchenko <email@example.com>
Subject: Re: pinctrl-cherryview regression in linux-next on preproduction Braswell
Date: Tue, 4 Jan 2022 15:47:36 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 1/4/22 15:38, Jarkko Nikula wrote:
> 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
> 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.
next prev parent reply other threads:[~2022-01-04 14:47 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 [this message]
2022-01-05 14:23 ` Jarkko Nikula
2022-01-10 15:44 ` Hans de Goede
2022-01-04 15:26 ` Mika Westerberg
2022-01-04 16:37 ` Hans de Goede
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.