Re: [PATCH] wlcore/wl18xx: Add invert-irq OF property for physically inverted IRQ

From: Harish Jenny K N
Date: Thu Jun 13 2019 - 12:53:53 EST



On 12/06/19 8:36 PM, Eugeniu Rosca wrote:
> Hi Marc,
>
> Thanks for your comment.
>
> On Wed, Jun 12, 2019 at 11:17:10AM +0100, Marc Zyngier wrote:
>> Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote:
>>> On Tue, Jun 11, 2019 at 10:00:41AM +0100, Marc Zyngier wrote:
> [..]
>>>> We already have plenty of that in the tree, the canonical example
>>>> probably being drivers/irqchip/irq-mtk-sysirq.c. It should be pretty
>>>> easy to turn this driver into something more generic.
>>> I don't think drivers/irqchip/irq-mtk-sysirq.c can serve the
>>> use-case/purpose of this patch. The MTK driver seems to be dealing with
>>> the polarity inversion of on-SoC interrupts which are routed to GiC,
>>> whereas in this patch we are talking about an off-chip interrupt
>>> wired to R-Car GPIO controller.
>> And how different is that? The location of the interrupt source is
>> pretty irrelevant here.
> The main difference which I sense is that a driver like irq-mtk-sysirq
> mostly (if not exclusively) deals with internal kernel implementation
> detail (tuned via DT) whilst adding an inverter for GPIO IRQs raises
> a whole bunch of new questions (e.g. how to arbitrate between
> kernel-space and user-space IRQ polarity configuration?).
>
>> The point is that there is already a general
>> scheme to deal with these "signal altering widgets", and that we
>> should try to reuse at least the concept, if not the code.
> Since Harish Jenny K N might be working on a new driver doing GPIO IRQ
> inversion, I have CC-ed him as well to avoid any overlapping work.


Sorry I am not completely aware of the background discussion.

But here is the link to my proposal for new consumer driver to provide a new virtual
gpio controller to configure the polarity of the gpio pins used by the userspace.

https://www.spinics.net/lists/linux-gpio/msg39681.html


>
>>> It looks to me that the nice DTS sketch shared by Linus Walleij in [5]
>>> might come closer to the concept proposed by Geert? FWIW, the
>>> infrastructure/implementation to make this possible is still not
>>> ready.
>> Which looks like what I'm suggesting.
> Then we are on the same page. Thanks.
>
>> M.
>>
>> --
>> Jazz is not dead, it just smells funny.