[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <TY1PR01MB17696E2B10CA447CD3508ADAF5CB0@TY1PR01MB1769.jpnprd01.prod.outlook.com>
Date: Tue, 6 Nov 2018 13:15:35 +0000
From: Phil Edworthy <phil.edworthy@...esas.com>
To: Marc Zyngier <marc.zyngier@....com>, Rob Herring <robh@...nel.org>
CC: Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
"linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/2] irqchip: Add support for Renesas RZ/N1 GPIO
interrupt multiplexer
Hi Marc,
On 31 October 2018 15:39, Phil Edworthy wrote
> On 31 October 2018 15:31, Marc Zyngier wrote:
> > On 31/10/18 15:09, Phil Edworthy wrote:
> > > On 31 October 2018 08:02, Marc Zyngier wote:
> > >> On Tue, 30 Oct 2018 10:44:38 +0000, Phil Edworthy wrote:
> > >>>
> > >>> On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> > >>> configured to have 32 interrupt outputs, so we have a total of 96
> > >>> GPIO interrupts. All of these are passed to the GPIO IRQ Muxer,
> > >>> which selects
> > >>> 8 of the GPIO interrupts to pass onto the GIC. The interrupt
> > >>> signals aren't latched, so there is nothing to do in this driver
> > >>> when an interrupt is received, other than tell the corresponding GPIO
> block.
<snip>
> > There are two cases:
> > 1) there is 1:1 mapping between a used input and an output, leaving
> > some input unused
> > 2) there is an n:1 mapping between input and output, and all the input
> > can be used at any given time
> >
> > If what you have is (1), you need to implement an hierarchy.
> > If what you have is (2), you need to implement a chained controller.
> >
> > (1) requires you to revisit this driver, making it a lot more like
> > ti's irq-crossbar
> > (2) requires you to actually do some decoding in the chained handler
> >
> > I believe you're in configuration (1). Am I right?
> Right, it's a 1:1 mapping. The information about which input to be used needs
> to be specified in dt.
> I didn’t think I could implement a hierarchy that didn’t mask the interrupts,
> so I need to go back over that and look again...
Ok, I have changed the driver to implement a hierarchy, i.e.
call irq_domain_create_hierarchy() in probe,
call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent()
in the irq_domain_ops.alloc function.
I've got a couple of issues that I hope you can provide some input on.
First is what to do with irqs that are input to this mux but not selected.
If I don't call irq_domain_set_hwirq_and_chip() and irq_domain_alloc_irqs_parent(),
it causes the driver for the hardware that generates these interrupts (in
this case, Synopsys dwapb_gpio) to throw an exception in
irq_set_chained_handler_and_data().
As a hack, I have simply used an unused output irq.
Second is specifying the output irqs. Currently, I specify them like this:
interrupts =
<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
...
<GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
However, I am only reading the property so I can pass the fwspec to
irq_domain_alloc_irqs_parent(). I am not using anything that ends up
in of_irq_parse_raw().
Rob H has previously said that I should use interrupt-map to describe the
relationship between the input and output irqs. Unfortunately, irq
hierarchy seems to be somewhat at odds with using interrupt-map.
Or at least, I can’t see how the two can be combined.
Your feedback on this is greatly appreciated!
Thanks
Phil
Powered by blists - more mailing lists