On 2014-12-03 14:04, Thomas Gleixner wrote: > On Wed, 3 Dec 2014, Arnd Bergmann wrote: > >> On Wednesday 03 December 2014 01:12:02 Stefan Agner wrote: >> > The inline function register_routable_domain_ops is only usable if >> > CONFIG_ARM_GIC is set. Make it depend on this configuration. This >> > also allows other SoC interrupt controller to provide such a >> > function. >> > >> > Signed-off-by: Stefan Agner <stefan@xxxxxxxx> >> >> I don't think this is a good idea: either the interface is meant >> to be generic and should work with any interrupt controller, or >> it is specific to one irqchip and another irqchip should provide >> a different interface that has a nonconflicting name. >> >> I suppose you want the latter here, given that the declaration >> is part of the gic specific header file. > > That routable_domain stuff should have never been invented. In > hindsight we should have done the stacked irq domains back then > already, but in hindsight ... I must admit that my first implementation even used arch_extn (through the mask/unmask stuff). Then I saw the routable domain stuff, which looked more like a fit. But when I realized that only GIC has support for that, I soon realized that this might either need a proper framework... my hackish NVIC extension probably won't be acceptable... Stack-able IRQ domain sounds like exactly what I was looking for... > > If you look at the crossbar scheme what we have now: > > GIC domain > |--------------| > | |---------- private > | non routable |---------- peripheral > | |---------- peripheral > | | > |--------------| > | |---------- peripheral > | routable |---------- peripheral > | | |---------- peripheral > |--------------| > | |----------------| > |-------------->| crossbar magic | > |----------------| > > which is not how the hardware looks. The hardware actually looks like > this: > > GIC domain > |--------------| > | |---------- private > | non routable |---------- peripheral > | |---------- peripheral > | | > |--------------| |--------------| > | | | |---------- peripheral > | routable |-----------| crossbar |---------- peripheral > | | | domain |---------- peripheral > |--------------| |--------------| > > So it is completely obvious that the peripheral interrupts which need > to be routed through the crossbar belong to a different domain. We > really should convert crossbar to that scheme and get rid of the > routable domain stuff completely. > > With vybrid thats not different according to the diagram in the > reference manual. > > GIC domain > |--------------| > | |---------- private > | non routable |---------- peripheral > | |---------- peripheral > | | > |--------------| |--------------| > | | | | > | routable |-----------| IRQ router | > | | | domain | > | | | | > |--------------| |--------------| > | Shared state |---------- CPU to CPU > NVIC domain | and hardware |---------- peripheral > |--------------| | |---------- peripheral > | | |--------------| > | | | | > | routable |-----------| IRQ router | > | | | domain | > | | | | > |--------------| |--------------| > | | > | |---------- private > | non routable |---------- peripheral > | |---------- peripheral > |--------------| > > The routable domain stuff is just an adhoc redirector which must be > tied to a particular base irq chip implementation (i.e. GIC). With > stacked irq domains there is no dependency on the underlying irq > chip. No ifdeffery, nothing. So you can use the same router domain > implementation for both the A5 and the M4 side. > > On the A5 side the router domain has the gic domain as parent and on > the M4 side the nvic domain. > > The shared interrupts are allocated through the router domain which > decides whether the interrupt can be assigned to a particular core or > not. If it can be assigned it allocates the corresponding interrupt in > the parent domain, sets up the routing and everything just works. What do you mean by the shared state in the drawing above? Currently, I check whether a interrupt is already used by the other core by reading the register (do this configuration register reflect the "shared state" in your drawing?). > > See: > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/irqdomain-arm > Thanks for the link. So my work would involve to support domain hierarchy for NVIC (proper irq_domain_ops, introduce arm,routable-irqs property, anything else?) and then make use of the hierarchy code in my MSCM driver like for instance the mtk-sysirq driver...? What is the state of the IRQ domain hierarchy, when will it go upstream? -- Stefan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
