On 10/01/2013 06:13 AM, Sricharan R wrote: > Hi, > > On Monday 30 September 2013 08:39 PM, Rob Herring wrote: >> On 09/30/2013 08:59 AM, Sricharan R wrote: >>> Some socs have a large number of interrupts requests to service >>> the needs of its many peripherals and subsystems. All of the interrupt >>> requests lines from the subsystems are not needed at the same >>> time, so they have to be muxed to the controllers appropriately. >>> In such places a interrupt controllers are preceded by an >>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt >>> requests to the controller inputs. >>> >>> This series models the peripheral interrupts that can be routed through >>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added >>> in a separate linear domain inside the GIC. The registered routable domain's >>> callback are invoked as a part of the GIC's callback, which in turn should >>> allocate a free irq line and configure the IP accordingly. So every peripheral >>> in the dts files mentions the fixed crossbar number as its interrupt. A free >>> gic line for that gets allocated and configured when the peripheral's interrupt >>> is mapped. >>> >>> The minimal crossbar driver to track and allocate free GIC lines and configure the >>> crossbar is added here, along with the DT bindings. >> Seems like interrupt-map property is what you need here. >> >> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping >> >> Versatile Express also has an example. > OK, but the idea was not to tie up the crossbar<->interrupt numbers at the > DTS level, but to assign it dynamically during runtime. This was one of the > comments that came up with first crossbar support patches, which was assigning a > interrupt line to crossbar number in the DTS and setting it up in crossbar probe. Is there an actual usecase on a single h/w design that you run out of interrupts and it is a user decision which interrupts to use? You could fill in the interrupt-map at run-time. It would have to be early (bootloader or early kernel init) and can't be at request_irq time. > https://lkml.org/lkml/2013/7/18/416 > > Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and > that did not go as well. Finally was asked to handle this as a part of GIC driver with > a separate domain. > > http://www.spinics.net/lists/linux-omap/msg97085.html This has nothing to do with the GIC, so it does not belong there. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
