[PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

Stefan Agner
2014-12-03T17:28:33Z

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@agner.ch>
>>
>> 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