Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
Hi Mark, Sorry for delayed response. I was away for some time. On Friday 15 November 2013 04:53 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 04:46:36PM +, Sricharan R wrote: Hi Mark, On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala ga...@codeaurora.org comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly +connected from the peripherals, but are routed dynamically +by a crossbar/multiplexer preceding the GIC. The GIC irq +input line is assigned dynamically when the corresponding +peripheral's crossbar line is mapped. I'm not keen on the design of the arm,routable-irqs property. The set of IRQs which the crossbar IP can use is a property of which IRQ lines it has routed to the GIC. I don't see why that should be considered a property of the GIC; it's a property of the crossbar IP's attachment to the GIC. Given we already have a mechanism for describing the attachment (i.e. the interrupts property) where the property appears on the node for the device generating/propagating the interrupt, I don't see why we should do differently here. We did try using interrupts= property for all peripherals and mapping them as crossbar's parent. But that approach of representing crossbar as a interrupt parent was not accepted, since the crossbar was just routing the interrupts from peripherals to GIC and nothing more. Also mapping all the interrupts using interrupt-map like property by a fixed way in DTS itself was considered hacky I'm not suggesting you should interrupt-map. I agree that that interrupt-map is not suitable for a dynamically configurable device like the crossbar. When you say that the crossbar is just routing the interrupts, at what level is it doing so? Does it accept a logical interrupt and output another logical interrupt, or does it just connect the two lines electrically? As Santosh, already mentioned this just makes a physical connection and thats it We don't necessarily have to use the interrupts property, but I still think that the set of GIC input IRQ lines that the crossbar is wired to should be described on the crossbar node. Listing 160 interrupts in the crossbar node is clearly something we don't want to have to do. If we had a property that we could use to define a range (or multiple ranges) of interrupts, then the crossbar driver could go and request those ranges from its interrupt-parent (the GIC) and the GIC driver could reserve/allocate the irqdomain at that time. Again, this kind of approach of crossbar requesting irqs from GIC was tried earlier and it did not go anywhere. Subsequently after lot of discussions this design was considered the best one. http://www.spinics.net/lists/linux-omap/msg97085.html As far as I can see, the
Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Thu, Nov 14, 2013 at 04:46:36PM +, Sricharan R wrote: Hi Mark, On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala ga...@codeaurora.org comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly +connected from the peripherals, but are routed dynamically +by a crossbar/multiplexer preceding the GIC. The GIC irq +input line is assigned dynamically when the corresponding +peripheral's crossbar line is mapped. I'm not keen on the design of the arm,routable-irqs property. The set of IRQs which the crossbar IP can use is a property of which IRQ lines it has routed to the GIC. I don't see why that should be considered a property of the GIC; it's a property of the crossbar IP's attachment to the GIC. Given we already have a mechanism for describing the attachment (i.e. the interrupts property) where the property appears on the node for the device generating/propagating the interrupt, I don't see why we should do differently here. We did try using interrupts= property for all peripherals and mapping them as crossbar's parent. But that approach of representing crossbar as a interrupt parent was not accepted, since the crossbar was just routing the interrupts from peripherals to GIC and nothing more. Also mapping all the interrupts using interrupt-map like property by a fixed way in DTS itself was considered hacky I'm not suggesting you should interrupt-map. I agree that that interrupt-map is not suitable for a dynamically configurable device like the crossbar. When you say that the crossbar is just routing the interrupts, at what level is it doing so? Does it accept a logical interrupt and output another logical interrupt, or does it just connect the two lines electrically? We don't necessarily have to use the interrupts property, but I still think that the set of GIC input IRQ lines that the crossbar is wired to should be described on the crossbar node. Listing 160 interrupts in the crossbar node is clearly something we don't want to have to do. If we had a property that we could use to define a range (or multiple ranges) of interrupts, then the crossbar driver could go and request those ranges from its interrupt-parent (the GIC) and the GIC driver could reserve/allocate the irqdomain at that time. Again, this kind of approach of crossbar requesting irqs from GIC was tried earlier and it did not go anywhere. Subsequently after lot of discussions this design was considered the best one. http://www.spinics.net/lists/linux-omap/msg97085.html As far as I can see, the comment there was to use irqdomains, which I am not arguing against. I am arguing that the linkage of the GIC and the crossbar is being
Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Friday 15 November 2013 06:23 AM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 04:46:36PM +, Sricharan R wrote: Hi Mark, On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala ga...@codeaurora.org comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly +connected from the peripherals, but are routed dynamically +by a crossbar/multiplexer preceding the GIC. The GIC irq +input line is assigned dynamically when the corresponding +peripheral's crossbar line is mapped. I'm not keen on the design of the arm,routable-irqs property. The set of IRQs which the crossbar IP can use is a property of which IRQ lines it has routed to the GIC. I don't see why that should be considered a property of the GIC; it's a property of the crossbar IP's attachment to the GIC. Given we already have a mechanism for describing the attachment (i.e. the interrupts property) where the property appears on the node for the device generating/propagating the interrupt, I don't see why we should do differently here. We did try using interrupts= property for all peripherals and mapping them as crossbar's parent. But that approach of representing crossbar as a interrupt parent was not accepted, since the crossbar was just routing the interrupts from peripherals to GIC and nothing more. Also mapping all the interrupts using interrupt-map like property by a fixed way in DTS itself was considered hacky I'm not suggesting you should interrupt-map. I agree that that interrupt-map is not suitable for a dynamically configurable device like the crossbar. When you say that the crossbar is just routing the interrupts, at what level is it doing so? Does it accept a logical interrupt and output another logical interrupt, or does it just connect the two lines electrically? Its just makes electrical connection between input and output line and thats it. 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
[PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
In some socs the gic can be preceded by a crossbar IP which
routes the peripheral interrupts to the gic inputs. The peripheral
interrupts are associated with a fixed crossbar input line and the
crossbar routes that to one of the free gic input line.
The DT entries for peripherals provides the fixed crossbar input line
as its interrupt number and the mapping code should associate this with
a free gic input line. This patch adds the support inside the gic irqchip
to handle such routable irqs. The routable irqs are registered in a linear
domain. The registered routable domain's callback should be implemented
to get a free irq and to configure the IP to route it.
Cc: Thomas Gleixner t...@linutronix.de
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Sricharan R r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[V2] Added default routable-irqs functions to avoid
unnecessary if checks as per Thomas Gleixner comments
and renamed routable-irq binding as per
Kumar Gala ga...@codeaurora.org comments.
[V3] Addressed unnecessary warn-on and updated default
xlate function as per Thomas Gleixner comments
Documentation/devicetree/bindings/arm/gic.txt |6 ++
drivers/irqchip/irq-gic.c | 81 ++---
include/linux/irqchip/arm-gic.h |7 ++-
3 files changed, 83 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..5357745 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -49,6 +49,11 @@ Optional
regions, used when the GIC doesn't have banked registers. The offset is
cpu-offset * cpu-nr.
+- arm,routable-irqs : Total number of gic irq inputs which are not directly
+ connected from the peripherals, but are routed dynamically
+ by a crossbar/multiplexer preceding the GIC. The GIC irq
+ input line is assigned dynamically when the corresponding
+ peripheral's crossbar line is mapped.
Example:
intc: interrupt-controller@fff11000 {
@@ -56,6 +61,7 @@ Example:
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
+ arm,routable-irqs = 160;
reg = 0xfff11000 0x1000,
0xfff10100 0x100;
};
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 9031171..b7b39a7 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -824,16 +824,25 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
irq_set_chip_and_handler(irq, gic_chip,
handle_fasteoi_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+
+ gic_routable_irq_domain_ops-map(d, irq, hw);
}
irq_set_chip_data(irq, d-host_data);
return 0;
}
+static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+ gic_routable_irq_domain_ops-unmap(d, irq);
+}
+
static int gic_irq_domain_xlate(struct irq_domain *d,
struct device_node *controller,
const u32 *intspec, unsigned int intsize,
unsigned long *out_hwirq, unsigned int
*out_type)
{
+ unsigned long ret = 0;
+
if (d-of_node != controller)
return -EINVAL;
if (intsize 3)
@@ -843,11 +852,20 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
*out_hwirq = intspec[1] + 16;
/* For SPIs, we need to add 16 more to get the GIC irq ID number */
- if (!intspec[0])
- *out_hwirq += 16;
+ if (!intspec[0]) {
+ ret = gic_routable_irq_domain_ops-xlate(d, controller,
+intspec,
+intsize,
+out_hwirq,
+out_type);
+
+ if (IS_ERR_VALUE(ret))
+ return ret;
+ }
*out_type = intspec[2] IRQ_TYPE_SENSE_MASK;
- return 0;
+
+ return ret;
}
#ifdef CONFIG_SMP
@@ -871,9 +889,41 @@ static struct notifier_block gic_cpu_notifier = {
const struct irq_domain_ops gic_irq_domain_ops = {
.map = gic_irq_domain_map,
+ .unmap = gic_irq_domain_unmap,
.xlate = gic_irq_domain_xlate,
};
+/* Default functions for routable irq domain */
+static int
Re: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Thu, 14 Nov 2013, Sricharan R wrote: [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Reviewed-by: Thomas Gleixner t...@linutronix.de -- 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: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Thursday 14 November 2013 06:03 PM, Thomas Gleixner wrote: On Thu, 14 Nov 2013, Sricharan R wrote: [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Reviewed-by: Thomas Gleixner t...@linutronix.de Thanks Thomas.. 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: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala ga...@codeaurora.org comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly + connected from the peripherals, but are routed dynamically + by a crossbar/multiplexer preceding the GIC. The GIC irq + input line is assigned dynamically when the corresponding + peripheral's crossbar line is mapped. I'm not keen on the design of the arm,routable-irqs property. The set of IRQs which the crossbar IP can use is a property of which IRQ lines it has routed to the GIC. I don't see why that should be considered a property of the GIC; it's a property of the crossbar IP's attachment to the GIC. Given we already have a mechanism for describing the attachment (i.e. the interrupts property) where the property appears on the node for the device generating/propagating the interrupt, I don't see why we should do differently here. Listing 160 interrupts in the crossbar node is clearly something we don't want to have to do. If we had a property that we could use to define a range (or multiple ranges) of interrupts, then the crossbar driver could go and request those ranges from its interrupt-parent (the GIC) and the GIC driver could reserve/allocate the irqdomain at that time. This feels like a point-hack, counter in style to the vast majority of provider/consumer bindings. It only allows for one multiplexer before the GIC. What if we had multiple multiplexers feeding into the GIC? Describing the attachment on the multiplexer allows that to be handled, describing that on the GIC does not. Describing the attachement on the multiplexer would also prevent the duplication of information (i.e. the max-irqs property in the crossbar binding). Thanks, Mark. -- 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: [PATCH V4 1/4] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
Hi Mark, On Thursday 14 November 2013 07:31 PM, Mark Rutland wrote: On Thu, Nov 14, 2013 at 12:18:47PM +, Sricharan R wrote: In some socs the gic can be preceded by a crossbar IP which routes the peripheral interrupts to the gic inputs. The peripheral interrupts are associated with a fixed crossbar input line and the crossbar routes that to one of the free gic input line. The DT entries for peripherals provides the fixed crossbar input line as its interrupt number and the mapping code should associate this with a free gic input line. This patch adds the support inside the gic irqchip to handle such routable irqs. The routable irqs are registered in a linear domain. The registered routable domain's callback should be implemented to get a free irq and to configure the IP to route it. Cc: Thomas Gleixner t...@linutronix.de Cc: Linus Walleij linus.wall...@linaro.org Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Rajendra Nayak rna...@ti.com Cc: Marc Zyngier marc.zyng...@arm.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Signed-off-by: Sricharan R r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- [V2] Added default routable-irqs functions to avoid unnecessary if checks as per Thomas Gleixner comments and renamed routable-irq binding as per Kumar Gala ga...@codeaurora.org comments. [V3] Addressed unnecessary warn-on and updated default xlate function as per Thomas Gleixner comments Documentation/devicetree/bindings/arm/gic.txt |6 ++ drivers/irqchip/irq-gic.c | 81 ++--- include/linux/irqchip/arm-gic.h |7 ++- 3 files changed, 83 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 3dfb0c0..5357745 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -49,6 +49,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly + connected from the peripherals, but are routed dynamically + by a crossbar/multiplexer preceding the GIC. The GIC irq + input line is assigned dynamically when the corresponding + peripheral's crossbar line is mapped. I'm not keen on the design of the arm,routable-irqs property. The set of IRQs which the crossbar IP can use is a property of which IRQ lines it has routed to the GIC. I don't see why that should be considered a property of the GIC; it's a property of the crossbar IP's attachment to the GIC. Given we already have a mechanism for describing the attachment (i.e. the interrupts property) where the property appears on the node for the device generating/propagating the interrupt, I don't see why we should do differently here. We did try using interrupts= property for all peripherals and mapping them as crossbar's parent. But that approach of representing crossbar as a interrupt parent was not accepted, since the crossbar was just routing the interrupts from peripherals to GIC and nothing more. Also mapping all the interrupts using interrupt-map like property by a fixed way in DTS itself was considered hacky Listing 160 interrupts in the crossbar node is clearly something we don't want to have to do. If we had a property that we could use to define a range (or multiple ranges) of interrupts, then the crossbar driver could go and request those ranges from its interrupt-parent (the GIC) and the GIC driver could reserve/allocate the irqdomain at that time. Again, this kind of approach of crossbar requesting irqs from GIC was tried earlier and it did not go anywhere. Subsequently after lot of discussions this design was considered the best one. http://www.spinics.net/lists/linux-omap/msg97085.html This feels like a point-hack, counter in style to the vast majority of provider/consumer bindings. It only allows for one multiplexer before the GIC. What if we had multiple multiplexers feeding into the GIC? Describing the attachment on the multiplexer allows that to be handled, describing that on the GIC does not. This is case where the interrupts to GIC is not coming from full irqchip, but just a router and support added in the GIC helps to handle such cases. In the case of more than one multiplexer, the crossbar driver should really take care of handling the downward muxes and crossbar like driver can be expanded to handle if such a scenario happens. Describing the attachement on the multiplexer would also prevent the duplication of information (i.e. the max-irqs property in the crossbar binding). Thanks, Mark. Here max-irqs is the
