From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chris Gorman <chrisjohgorman@gmail.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
<theadamlevy@gmail.com>
Subject: Re: [PATCH] pinctrl: cherryview: fix issues caused by dynamic gpio irqs mapping
Date: Tue, 3 Oct 2017 13:20:05 -0500 [thread overview]
Message-ID: <1ff05c6b-9bac-b8e7-fb10-cd146e4e8bf8@ti.com> (raw)
In-Reply-To: <CAHp75Vce0v0d9x4AiDnbNfqv4c_erxwNXsd+ApCTEfybCEOMdA@mail.gmail.com>
On 10/03/2017 12:54 PM, Andy Shevchenko wrote:
> On Tue, Oct 3, 2017 at 8:00 PM, Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> New GPIO IRQs are allocated and mapped dynamically by default when
>> GPIO IRQ infrastructure is used by cherryview-pinctrl driver.
>> This causes issues on some Intel platforms [1][2] with broken BIOS which
>> hardcodes Linux IRQ numbers in their ACPI tables.
>>
>> On such platforms cherryview-pinctrl driver should allocate and map all
>> GPIO IRQs at probe time.
>> Side effect - "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n"
>> can be seen at boot log.
>>
>> NOTE. It still may fail if boot sequence will changed and some interrupt
>> controller will be probed before cherryview-pinctrl which will shift Linux IRQ
>> numbering (expected with CONFIG_SPARCE_IRQ enabled).
>>
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=194945
>> [2] https://lkml.org/lkml/2017/9/28/153
>
> Btw, you might want to use one of
>
> Buglink:
> Bugzilla:
> Link:
>
> tags.
>
>> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Cc: Chris Gorman <chrisjohgorman@gmail.com>
>> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
>> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> Reported-by: Chris Gorman <chrisjohgorman@gmail.com>
>> Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>
> I'm not sure about this approach. It might be some other broken BIOS
> discovered with some other driver (like pinctrl-baytrail.c as an
> hypothetical example).
It can be made more safe by fixing gpio chip base irq numbers, but this info
should be passed to drivers somehow. Of course, above note will be still valid
- as W/A, required IRQ ranges can be reserved very early during boot in platform code.
>
> Alternative is to deselect SPARSE_IRQ (though it makes it non-usable
> in entire x86 world).
:) nuke mix.
>
>> drivers/pinctrl/intel/pinctrl-cherryview.c | 14 +++++++++++++-
>> 1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
>> index 04e929f..fadbca9 100644
>> --- a/drivers/pinctrl/intel/pinctrl-cherryview.c
>> +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
>> @@ -1577,6 +1577,7 @@ static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
>> struct gpio_chip *chip = &pctrl->chip;
>> bool need_valid_mask = !dmi_check_system(chv_no_valid_mask);
>> int ret, i, offset;
>> + int irq_base;
>>
>> *chip = chv_gpio_chip;
>>
>> @@ -1622,7 +1623,18 @@ static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
>> /* Clear all interrupts */
>> chv_writel(0xffff, pctrl->regs + CHV_INTSTAT);
>>
>> - ret = gpiochip_irqchip_add(chip, &chv_gpio_irqchip, 0,
>> + if (!need_valid_mask) {
>> + irq_base = devm_irq_alloc_descs(pctrl->dev, -1, 0,
>> + chip->ngpio, NUMA_NO_NODE);
>> + if (irq_base < 0) {
>> + dev_err(pctrl->dev, "Failed to allocate IRQ numbers\n");
>> + return irq_base;
>> + }
>> + } else {
>> + irq_base = 0;
>> + }
>> +
>> + ret = gpiochip_irqchip_add(chip, &chv_gpio_irqchip, irq_base,
>> handle_bad_irq, IRQ_TYPE_NONE);
>> if (ret) {
>> dev_err(pctrl->dev, "failed to add IRQ chip\n");
>> --
>> 2.10.1
>>
>
>
>
--
regards,
-grygorii
next prev parent reply other threads:[~2017-10-03 18:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-03 17:00 Grygorii Strashko
2017-10-03 17:54 ` Andy Shevchenko
2017-10-03 18:20 ` Grygorii Strashko [this message]
2017-10-04 6:41 ` Mika Westerberg
2017-10-04 6:42 ` Mika Westerberg
2017-10-06 8:19 ` Mika Westerberg
2017-10-06 13:02 ` Chris Gorman
2017-10-04 17:01 ` Chris Gorman
2017-10-08 0:42 ` Linus Walleij
2017-10-09 18:04 ` Grygorii Strashko
2017-10-04 16:07 Chris Gorman
2017-10-04 16:25 ` Mika Westerberg
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=1ff05c6b-9bac-b8e7-fb10-cd146e4e8bf8@ti.com \
--to=grygorii.strashko@ti.com \
--cc=andy.shevchenko@gmail.com \
--cc=chrisjohgorman@gmail.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=theadamlevy@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome