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

[Eugeniu Rosca <erosca@de.adit-jv.com>]

Hi Marc,

Thanks for your comment.

On Wed, Jun 12, 2019 at 11:17:10AM +0100, Marc Zyngier wrote:
> Eugeniu Rosca <erosca@de.adit-jv.com> 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.

> 
> > 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.

-- 
Best Regards,
Eugeniu.