To summaries it again, what I understood from Sricharan's proposal,Ack.
- Setup all the routing at cross-bar probe so that kernel continue to
work like normal IRQ controller with cross-bar scope vanishes once
the routing is done. Cross-bar does this before any of the devices
are created.
- Something similar needs to happen for DMA lines as well or for any
other event routing in future.
- Cross-bar callbacks for device drivers for error paths.
(Sricharan, you have to drop these because it doesn't bring any
functionality and rather can create a side effects of drivers
getting polluted.)
Unfortunately, we do have a constraint without allocating dynamic IRQs - what IP instances should hwmod and dts contain?
The concern raised on above was instead of fixing the routing at DT
statically, doing at the driver probes where the loop-up for IRQ or DMA
lines should happen in background transparently on drivers call of
request_irq/request_dma_channel etc with cross-bar number as
an input to it. Though it will be nice to have
such feature, it doesn't bring anything special and brings the
notion of these APIs which expect that you know what IRQ and DMA
lines you want while calling these.
We could look at it as a signal mux problem as this thread suggests OR look at it as interrupt distribution problem (which is how it looks like at the face of it). That said, maybe a intermediate pinctrl approach might be more pragmatic and less theoretically flexible.
Note that mux inputs are pretty much fixed. Its his connection
to IRQ controller or DMA controller is what needs to be programmed.
So scope is pretty much limited. I felt this requirement is pretty
similar to pin-mux and hence thought of it as a viable option.
Having said all of above, if there is a better alternative than
enhanced pin-mux we surely can do that.