On Mon, Jun 13, 2016 at 05:46:19PM +0200, Sebastian Frias wrote: > My understanding of "hierarchical irq domains" is that it is useful when > there are multiple stacked interrupt controllers. > Also, the documentation says "the majority of drivers should use the linear > map" (as opposed to the hierarchical one). > > Maybe the definition of "interrupt controller" could benefit from some > clarification, but my understanding is that, in our case, the GIC is the only > interrupt controller (that's where the interrupt type must be set > active_high/active_low/edge, etc.), in front of it, it happens to be a > crossbar, that happens to be programmable, and that can be used to map any > 128 line into any of 24 lines of the GIC (actually it is a many-to-many > router, without any latching nor edge detection functionality) > > Obviously, when the DT says that ethernet driver uses IRQ=120 (for example), > the crossbar must be setup to route line 120 to one of the 24 lines going to > the GIC. > So a minimum of interaction between the GIC driver (and/or the Linux IRQ > framework) and the driver programming the crossbar is required, and that's > what we are trying to achieve. > > Does that makes sense?
Well something has to tell the crossbar to map 120 to one of the 24. Of course the driver for the device needs to be told to use the one of the 24 it was mapped to. As far as I recall the TI irq-crossbar allows you to specify in the DT that you want to use a given input to the crossbar for a given device, and it dynamically allocated a mapping to a free IRQ on the CPU and maps it and the driver is told the correct interrupt to use for that device. Pretty handy. With older versions of the driver you had to setup all the maps manually in the devicetree and manually assign the correct IRQ to the driver, which was more error prone of course and a bit of a hassle. -- Len Sorensen
