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: Mon, 3 Jan 2022 14:34:48 +0200 [thread overview]
Message-ID: <a8b6d8f1-ad8c-23ac-a85b-2c903530735f@linux.intel.com> (raw)
In-Reply-To: <6d133b89-cc03-6308-6da7-dcea95a93a8c@redhat.com>
Hi
On 1/3/22 12:42, Hans de Goede wrote:
> Hi Jarkko,
>
> On 1/3/22 10:42, Jarkko Nikula wrote:
>> Hi
>>
>> We have a Braswell based preproduction HW. I noticed linux-next tag next-20211224 doesn't boot on it due to following error:
>>
>> [ 34.674271] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
>> [ 34.682476] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
>> [ 34.690681] cherryview-pinctrl INT33FF:00: interrupt on unused interrupt line 0
>> ...
>>
>> Linux v5.16-rc8 is ok. I found the following commit to be reason for the regression:
>>
>> bdfbef2d29dc ("pinctrl: cherryview: Don't use selection 0 to mark an interrupt line as unused")
>
> Thank you for the timely headsup about this.
>
> I assume that you have tried a revert (if necessary including reverting some
> of the follow ups) and that reverting the patch you point to fixes the
> issue, right ?
>
Yes since linux-next has only these three commits below to
pinctrl-cherryview.c that are not in v5.16-rc8 I reverted them one by
one. I often try these kind of simple steps before going to more labor
git bisect :-)
db1b2a8caf5b pinctrl: cherryview: Use temporary variable for struct device
07199dbf8cae pinctrl: cherryview: Do not allow the same interrupt line
to be used by 2 pins
bdfbef2d29dc pinctrl: cherryview: Don't use selection 0 to mark an
interrupt line as unused
I also double checked by checking out to bdfbef2d29dc and tested that
commit and it reverted.
> Can you try the 2 attached patches *one at a time* ? :
>
> 1. Restores the old behavior of just triggering hwirq 0 of
> the pincontroller-domain when we don't know the mapping
>
Patch 1 does work and here's the output from modified error print:
[ 13.550781] cherryview-pinctrl INT33FF:00: interrupt on unmapped
interrupt line 0
If you want to go with patch 1 you may add my
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> 2. Restores the old behavior which allows chv_gpio_irq_startup()
> to overwrite the interrupt-line to pin mapping if the current
> mapping points to pin 0
>
Patch 2 alone doesn't:
[ 24.977116] cherryview-pinctrl INT33FF:00: interrupt on unused
interrupt line 0
[ 24.985314] cherryview-pinctrl INT33FF:00: interrupt on unused
interrupt line 0
[ 24.993513] cherryview-pinctrl INT33FF:00: interrupt on unused
interrupt line 0
...
> Both of these restore old behavior caused by a mapping-table
> entry containing 0 meaning both unset as well as HWIRQ0
> before the patch in question.
>
> If applying them one at a time does not help, please also try with
> both applied.
>
> These 2 patches should apply cleanly on top of linux-next.
>
> If patch 2 fixes things it would be interesting if you can grab a
> dmesg with "pinctrl-cherryview.dyndbg" added to the command line
> (with the patched kernel).
>
With both applied it does work:
# dmesg |grep cherryview-pinctrl
[ 15.465425] cherryview-pinctrl INT33FF:00: interrupt on unmapped
interrupt line 0
[ 16.562282] cherryview-pinctrl INT33FF:03: using interrupt line 0 for
pin 81
[ 17.824905] cherryview-pinctrl INT33FF:02: using interrupt line 0 for
pin 22
[ 17.835757] cherryview-pinctrl INT33FF:03: using interrupt line 2 for
pin 77
[ 17.850170] cherryview-pinctrl INT33FF:00: using interrupt line 0 for
pin 76
Jarkko
next prev parent reply other threads:[~2022-01-03 12:34 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 [this message]
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
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a8b6d8f1-ad8c-23ac-a85b-2c903530735f@linux.intel.com \
--to=jarkko.nikula@linux.intel.com \
--cc=andy@kernel.org \
--cc=hdegoede@redhat.com \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.