[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <580F0244.7070701@baylibre.com>
Date: Tue, 25 Oct 2016 08:57:08 +0200
From: Neil Armstrong <narmstrong@...libre.com>
To: Linus Walleij <linus.walleij@...aro.org>,
Andrey Smirnov <andrew.smirnov@...il.com>
CC: Peter Rosin <peda@...ntia.se>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Roland Stigge <stigge@...com.de>,
Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Subject: Re: [PATCH v3] pinctrl: Add SX150X GPIO Extender Pinctrl Driver
Hi Linus,
Le 24/10/2016 16:39, Linus Walleij a écrit :
> On Mon, Oct 24, 2016 at 6:51 AM, Andrey Smirnov
> <andrew.smirnov@...il.com> wrote:
>
>> It seem strange to me that the driver uses "handle_edge_irq", given
>> how none of the individual interrupts seem to require any ACKing,
>> since it is all handled in sx150x_irq_thread_fn(), line 533. More so,
>> I had trouble finding who/where sets .irq_ack() callback, which AFAIU
>> is mandatory for handle_edge_irq().
>
> Yes that looks strange.
>
> Neil have you tested IRQs with this code?
To be frank, I took the IRQ code from the GPIO driver verbatim, and only tested
a simple use case on beagle bone black.
The interrupt code is very complex and sincerely I was not able to understand
clearly how it worked.
The IRQ_TYPE_EDGE_BOTH did work for me since the BBB irq controller dealt with it.
I will dig in the datasheet and run more uses cases next week, but since the
code hasn't changed since the GPIO driver, so this is a nice to have !
>
> If there is trouble, please follow up with a fix for the edge handler.
> Maybe it should just be handle_simple_irq().
>
> Yours,
> Linus Walleij
>
Andrey, can we talk over irc somehow ? I'm idling as narmstrong on freenode.
Neil
Powered by blists - more mailing lists