Messages in this thread | | | Subject | Re: [RFC PATCH v1] irqchip: add support for SMP irq router | From | Marc Zyngier <> | Date | Thu, 7 Jul 2016 13:42:36 +0100 |
| |
On 07/07/16 13:16, Sebastian Frias wrote: > Hi Marc, > > On 07/06/2016 03:50 PM, Marc Zyngier wrote: >>> I think that's where part the misunderstanding comes from. >>> IMHO the output line is not a direct function of the input line. >>> Any of the 64 IRQ lines entering the "old controller" (irq-tango.c) can be >>> routed to any of its 3 outputs. >> >> Then the current DT binding isn't properly describing the HW. > > Ok, thanks, so it is not a good example then. > >>> In a nutshell: >>> - "old controller": routes [0...N] => GIC inputs [2...4] >>> - "new controller": routes [0...M] => GIC inputs [0...23] >>> >>> So, when we think about it, if the "new DT" specified 24 domains, it would >>> be equivalent of the "old DT" with 3 domains, right? >> >> Indeed, but I consider the "old" binding to be rather misleading. It >> should have been described as a router too, rather than hardcoding >> things in DT. Granted, it doesn't matter much when you only have 3 >> possible output lines. But with 24 outputs, that becomes much more relevant. > > I see. > >>> So, putting aside routing considerations and the discussion above, I think >>> a simpler question is: if the domains should not be described in the DT, >>> how can we define the IRQ sharing in the DT? >> >> You could have a set of sub-nodes saying something like this: >> >> mux-hint0 { >> inputs = <1 45 127>; >> } >> >> mux-hint1 { >> inputs = <2 33>; >> } >> >> (or maybe you can have that as direct properties, but you get the idea). >> Here, you have two output pins dedicated to muxed interrupts (assuming >> they are all level interrupts), and the last 22 can be freely allocated >> as direct routes. >> > > Ok, I'll try to do that. > So, aside from the DT issues (that is, that it is describing domains), > would it be ok to create a domain for each of the outputs? > > Because I was looking at: > - Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt > - drivers/irqchip/exynos-combiner.c > - arch/arm/boot/dts/exynos4210.dtsi > > and what I see is that the DT basically list all outputs [0...15] connected > to the parent interrupt controller, although the driver does not creates > separate domains, just one. Then it attaches a chained handler for each of > the outputs. On the .map callback it attaches a irqchip to the domain. > > There is also: > - Documentation/devicetree/bindings/arm/omap/crossbar.txt > - drivers/irqchip/irq-crossbar.c > - arch/arm/boot/dts/dra7.dtsi > > This one creates a domain hierarchy linked to the parent domain and uses > irq_domain_alloc_irqs_parent() and irq_domain_set_hwirq_and_chip() to attach > a irqchip to the domain on the .alloc callback. > > Both use a single domain, as opposed to irq-tango.c which creates 3 domains. > Right now irq-tango_v2.c is supposed to create one domain per output (if > so the DT says) > Are there guidelines regarding that?
The sensible thing would be to have one domain per output that muxes inputs, and a hierarchical domain for all the other inputs (which are mapped 1:1 with their output).
Thanks,
M. -- Jazz is not dead. It just smells funny...
| |