Hi Tony,

On 2/20/2019 10:06 PM, Tony Lindgren wrote:

Hi,

Some more info on chained irq vs mux below that might
help.

* Tony Lindgren [off-list ref] [190219 15:36]:

quoted

* Lokesh Vutla [off-list ref] [190219 08:51]:

quoted

With this can you tell me how can we not have a device-tree and still support
irq allocation?

Using standard dts reg property to differentiate the interrupt
router instances. And if the interrupt router is a mux, you should
treat it as a mux rather than a chained interrupt controller.

We do have drivers/mux nowadays, not sure if it helps in this case
as at least timer interrupts need to be configured very early.

Adding Linus Walleij to Cc since he posted a good test to
consider if something should use chained (or nested) irq:

"individual masking and ACKing bits and can all be used at the
 same time" [0]

Interrupt Router just routes M inputs to N outputs. One input can only
be mapped to one output. This is a clear case of a hierarchical domain
and the driver is implementing it.

Thanks and regards,
Lokesh

Not sure if we have that documented somewhere?

But seems like the interrupt router should be set up as
a separate mux driver talking with firmware that the
interrupt controller driver calls on request_irq(>
Cheers,

Tony


[0] https://marc.info/?l=linux-omap&m=155065629529311&w=2

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel