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
