Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On Tue, 1 Oct 2013, Rob Herring wrote: > On 10/01/2013 06:13 AM, Sricharan R wrote: > > 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? I don't think that matters. What matters is that you have a single DT entry which tells the driver which crossbar irq to use for that particular device. And that is the only information which is relevant because the IP block is connected to a crossbar input and not to a GIC line. The crossbar provides the mapping and this is really best done at runtime w/o having hardcoded information in the DT or at some other place. > 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. How is that supposed to work when you have no idea at early boot time which particular IP blocks are going to be used later on? > > http://www.spinics.net/lists/linux-omap/msg97085.html > > This has nothing to do with the GIC, so it does not belong there. Errm. crossbar is a mapping device which happens to sit between the GIC and the IP blocks. So how is this NOT related to GIC ? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
Hi Thomas, On Tuesday 01 October 2013 08:37 PM, Santosh Shilimkar wrote: > On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote: >> On 10/01/2013 08:57 AM, Santosh Shilimkar wrote: >>> On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: 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? >>> Yes. There are 240 peripheral interrupts connected out of which 160 can >>> be used in this specific case. >> Yes, I understand the SOC connections. That does not answer my question. >> The 240 interrupts are likely to be limited to fewer by board design, >> pinmuxing, etc. >> > yes limited by different board designs ... > >> How do you handle the 161st interrupt request? Will never happen? Just >> rely on the random driver probe ordering? >> > Well the board dts are expected to provide the peripheral support info to > optimise it. > If a board actually has more than 160 peripherals available then in that > case the 161 interrupt will not be mapped. > 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. >>> Well all options are tried before coming up to the $subject solution. >>> It was suggested by Thomas in the last review. >>> > 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. >>> Well the router makes connections from peripheral to GIC. Thomas can >>> better explain it but I think since its doing irq routing for GIC on >>> a given hardware, I don't see any issue having some generic map/unmap >>> function in GIC. The actual implementation is still outside of GIC. >> I read Thomas' reply as don't put this crap in his code. >> > That was for the IRQCHIP based approach and as part of that review > Thomas suggested why not irqdomain and suggested a prototype code > as well. > >> You can call it generic, but it is not. It is specific to the GIC and >> looks like an abuse of irqdomains to me. Look where the function >> declaration for register_routable_domain_ops is. >> > I am not sure why you call it abuse of irqdomain since the map/unmap > are exactly the interfaces where the logical to physical irq > connections are made. Look at existing GIC code as well. I still > let Thomas give his expert comment whether it is abusive because it > it was, am sure he wouldn't have suggested that. Is this inline with what you were suggesting and is this approach fine ? Regards, Sricharan -- To unsubscribe from this list: send the
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote: > On 10/01/2013 08:57 AM, Santosh Shilimkar wrote: >> On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: >>> 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? >>> >> Yes. There are 240 peripheral interrupts connected out of which 160 can >> be used in this specific case. > > Yes, I understand the SOC connections. That does not answer my question. > The 240 interrupts are likely to be limited to fewer by board design, > pinmuxing, etc. > yes limited by different board designs ... > How do you handle the 161st interrupt request? Will never happen? Just > rely on the random driver probe ordering? > Well the board dts are expected to provide the peripheral support info to optimise it. If a board actually has more than 160 peripherals available then in that case the 161 interrupt will not be mapped. >>> 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. >>> >> Well all options are tried before coming up to the $subject solution. >> It was suggested by Thomas in the last review. >> 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. >>> >> Well the router makes connections from peripheral to GIC. Thomas can >> better explain it but I think since its doing irq routing for GIC on >> a given hardware, I don't see any issue having some generic map/unmap >> function in GIC. The actual implementation is still outside of GIC. > > I read Thomas' reply as don't put this crap in his code. > That was for the IRQCHIP based approach and as part of that review Thomas suggested why not irqdomain and suggested a prototype code as well. > You can call it generic, but it is not. It is specific to the GIC and > looks like an abuse of irqdomains to me. Look where the function > declaration for register_routable_domain_ops is. > I am not sure why you call it abuse of irqdomain since the map/unmap are exactly the interfaces where the logical to physical irq connections are made. Look at existing GIC code as well. I still let Thomas give his expert comment whether it is abusive because it it was, am sure he wouldn't have suggested that. Now if your concern is the register_routable_domain_ops() then we are open to hear if there is any better way to do that. Thats why the series is still RFC. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordo
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On 10/01/2013 08:57 AM, Santosh Shilimkar wrote: > On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: >> 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? >> > Yes. There are 240 peripheral interrupts connected out of which 160 can > be used in this specific case. Yes, I understand the SOC connections. That does not answer my question. The 240 interrupts are likely to be limited to fewer by board design, pinmuxing, etc. How do you handle the 161st interrupt request? Will never happen? Just rely on the random driver probe ordering? >> 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. >> > Well all options are tried before coming up to the $subject solution. > It was suggested by Thomas in the last review. > >>> 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. >> > Well the router makes connections from peripheral to GIC. Thomas can > better explain it but I think since its doing irq routing for GIC on > a given hardware, I don't see any issue having some generic map/unmap > function in GIC. The actual implementation is still outside of GIC. I read Thomas' reply as don't put this crap in his code. You can call it generic, but it is not. It is specific to the GIC and looks like an abuse of irqdomains to me. Look where the function declaration for register_routable_domain_ops is. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote: > 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? > Yes. There are 240 peripheral interrupts connected out of which 160 can be used in this specific case. > 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. > Well all options are tried before coming up to the $subject solution. It was suggested by Thomas in the last review. >> 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. > Well the router makes connections from peripheral to GIC. Thomas can better explain it but I think since its doing irq routing for GIC on a given hardware, I don't see any issue having some generic map/unmap function in GIC. The actual implementation is still outside of GIC. Regards, Sasntosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
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-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
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. 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 Regards, Sricharan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
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. Rob > > Sricharan R (6): > DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs > DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP > ARM: DTS: DRA: Add crossbar device binding > ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar > inputs. > ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number > ARM: DRA: Enable Crossbar IP support for DRA7XX > > Documentation/devicetree/bindings/arm/gic.txt |5 + > .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++ > arch/arm/boot/dts/dra7.dtsi| 98 +- > arch/arm/mach-omap2/Kconfig|1 + > arch/arm/mach-omap2/omap-wakeupgen.c |4 +- > arch/arm/mach-omap2/omap4-common.c |4 + > drivers/irqchip/Kconfig|8 + > drivers/irqchip/Makefile |1 + > drivers/irqchip/irq-crossbar.c | 195 > > drivers/irqchip/irq-gic.c | 57 +- > include/linux/irqchip/arm-gic.h|8 +- > include/linux/irqchip/irq-crossbar.h | 11 ++ > 12 files changed, 363 insertions(+), 56 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt > create mode 100644 drivers/irqchip/irq-crossbar.c > create mode 100644 include/linux/irqchip/irq-crossbar.h > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
On Monday 30 September 2013 09: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. > You should have references to the previous discussions so that its easier for new reviewers to understand why you ended up the approach. I noticed you missed this in your last posts as well. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
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. Sricharan R (6): DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP ARM: DTS: DRA: Add crossbar device binding ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs. ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number ARM: DRA: Enable Crossbar IP support for DRA7XX Documentation/devicetree/bindings/arm/gic.txt |5 + .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++ arch/arm/boot/dts/dra7.dtsi| 98 +- arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/omap-wakeupgen.c |4 +- arch/arm/mach-omap2/omap4-common.c |4 + drivers/irqchip/Kconfig|8 + drivers/irqchip/Makefile |1 + drivers/irqchip/irq-crossbar.c | 195 drivers/irqchip/irq-gic.c | 57 +- include/linux/irqchip/arm-gic.h|8 +- include/linux/irqchip/irq-crossbar.h | 11 ++ 12 files changed, 363 insertions(+), 56 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt create mode 100644 drivers/irqchip/irq-crossbar.c create mode 100644 include/linux/irqchip/irq-crossbar.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
