irq_create_fwspec_mapping() in 4.8-rc2
Nicolas Ferre
nicolas.ferre at atmel.com
Mon Sep 5 06:10:32 PDT 2016
Le 05/09/2016 à 14:40, Linus Walleij a écrit :
> On Fri, Sep 2, 2016 at 5:31 PM, Marc Zyngier <marc.zyngier at arm.com> wrote:
>
>> +Linus, Jean-Christophe, Jon
>>
>> On 02/09/16 16:15, Andras Szemzo wrote:
>>> Hi,
>>>
>>>> On 02 Sep 2016, at 17:09, Marc Zyngier <marc.zyngier at arm.com> wrote:
>>>>
>>>> So something has already configured the interrupt to be
>>>> IRQ_TYPE_EDGE_BOTH, and this clashes with your
>>>> IRQ_TYPE_EDGE_FALLING.
>>>>
>>>> My bet is on this one:
>>>>
>>>> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
>>>> index 80daead..9f09041 100644
>>>> --- a/drivers/pinctrl/pinctrl-at91.c
>>>> +++ b/drivers/pinctrl/pinctrl-at91.c
>>>> @@ -1614,7 +1614,7 @@ static int at91_gpio_of_irq_setup(struct platform_device *pdev,
>>>> &gpio_irqchip,
>>>> 0,
>>>> handle_edge_irq,
>>>> - IRQ_TYPE_EDGE_BOTH);
>>>> + IRQ_TYPE_NONE);
>>>> if (ret) {
>>>> dev_err(&pdev->dev, "at91_gpio.%d: Couldn't add irqchip to gpiochip.\n",
>>>> at91_gpio->pioc_idx);
>>>>
>>>> Can you give it a go and let me know what happens?
>>>
>>> yes, this fixed the problem. Thank you, it was fast!
>>
>> Right. So the at91 pinctlr seems to enforce a default configuration. The
>> question is *why*? All interrupts connected to it should provide their
>> own trigger coming from DT.
>
> I guess for legacy boardfile usecases or just how it happened to end
> up during development.
>
>> As we now actually check that we have some consistency between what is
>> configured and what is requested, it is bound to fail, unless you happen
>> to match the default.
>
> Which is good!
>
>> What am I missing?
>
> Nothing, I am missing your patch on the mailing list with a Signed-off-by
> so I can apply it (unless the Atmel people have complaints).
Absolutely no complains, I've only noticed this discussion at the moment.
Thanks Marc and Andras!
Bye,
--
Nicolas Ferre
More information about the linux-arm-kernel
mailing list