* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-09-30 13:59 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
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 <tglx@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 5 +++
arch/arm/boot/dts/dra7.dtsi | 1 +
drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
include/linux/irqchip/arm-gic.h | 8 +++-
4 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..2d8c680 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.
+- 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 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..b35cb12 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -55,6 +55,7 @@
compatible = "arm,cortex-a15-gic";
interrupt-controller;
#interrupt-cells = <3>;
+ routable_irqs = <160>;
reg = <0x48211000 0x1000>,
<0x48212000 0x1000>;
};
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1760ceb..c5778ab 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -72,6 +72,8 @@ struct gic_chip_data {
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+const struct irq_domain_ops *gic_routable_irq_domain_ops;
+
/*
* The GIC mapping of CPU interfaces does not necessarily match
* the logical CPU numbering. Let's use a mapping as returned
@@ -675,11 +677,26 @@ 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);
+
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->map)
+ 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)
+{
+ irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+
+ if (hw > 32) {
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->unmap)
+ 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,
@@ -694,8 +711,15 @@ 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]) {
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->xlate)
+ *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
+ controller, intspec, intsize,
+ out_hwirq, out_type);
+ else
+ *out_hwirq += 16;
+ }
*out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
return 0;
@@ -722,6 +746,7 @@ static struct notifier_block __cpuinitdata 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,
};
@@ -732,6 +757,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
int gic_irqs, irq_base, i;
+ int nr_routable_irqs;
BUG_ON(gic_nr >= MAX_GIC_NR);
@@ -797,14 +823,27 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
gic->gic_irqs = gic_irqs;
gic_irqs -= hwirq_base; /* calculate # of irqs to allocate */
- irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
- if (IS_ERR_VALUE(irq_base)) {
- WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
- irq_start);
- irq_base = irq_start;
+
+ if (of_property_read_u32(node, "routable_irqs", &nr_routable_irqs)) {
+ irq_base = irq_alloc_descs(irq_start, 16, gic_irqs,
+ numa_node_id());
+ if (IS_ERR_VALUE(irq_base)) {
+ WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+ irq_start);
+ irq_base = irq_start;
+ }
+
+ gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
+ hwirq_base, &gic_irq_domain_ops, gic);
+ } else {
+ if (WARN_ON(!gic_routable_irq_domain_ops))
+ return;
+
+ gic->domain = irq_domain_add_linear(node, nr_routable_irqs,
+ &gic_irq_domain_ops,
+ gic);
}
- gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
- hwirq_base, &gic_irq_domain_ops, gic);
+
if (WARN_ON(!gic->domain))
return;
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3e203eb..fd4192a 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -73,6 +73,12 @@ static inline void gic_init(unsigned int nr, int start,
gic_init_bases(nr, start, dist, cpu, 0, NULL);
}
-#endif /* __ASSEMBLY */
+extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
+static inline void __init register_routable_domain_ops
+ (const struct irq_domain_ops *ops)
+{
+ gic_routable_irq_domain_ops = ops;
+}
+#endif /* __ASSEMBLY */
#endif
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: mark.rutland, linux, r.sricharan, tony, linus.walleij, rnayak,
rob.herring, marc.zyngier, santosh.shilimkar, grant.likely, tglx
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 <tglx@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 5 +++
arch/arm/boot/dts/dra7.dtsi | 1 +
drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
include/linux/irqchip/arm-gic.h | 8 +++-
4 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..2d8c680 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.
+- 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 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..b35cb12 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -55,6 +55,7 @@
compatible = "arm,cortex-a15-gic";
interrupt-controller;
#interrupt-cells = <3>;
+ routable_irqs = <160>;
reg = <0x48211000 0x1000>,
<0x48212000 0x1000>;
};
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1760ceb..c5778ab 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -72,6 +72,8 @@ struct gic_chip_data {
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+const struct irq_domain_ops *gic_routable_irq_domain_ops;
+
/*
* The GIC mapping of CPU interfaces does not necessarily match
* the logical CPU numbering. Let's use a mapping as returned
@@ -675,11 +677,26 @@ 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);
+
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->map)
+ 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)
+{
+ irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+
+ if (hw > 32) {
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->unmap)
+ 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,
@@ -694,8 +711,15 @@ 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]) {
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->xlate)
+ *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
+ controller, intspec, intsize,
+ out_hwirq, out_type);
+ else
+ *out_hwirq += 16;
+ }
*out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
return 0;
@@ -722,6 +746,7 @@ static struct notifier_block __cpuinitdata 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,
};
@@ -732,6 +757,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
int gic_irqs, irq_base, i;
+ int nr_routable_irqs;
BUG_ON(gic_nr >= MAX_GIC_NR);
@@ -797,14 +823,27 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
gic->gic_irqs = gic_irqs;
gic_irqs -= hwirq_base; /* calculate # of irqs to allocate */
- irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
- if (IS_ERR_VALUE(irq_base)) {
- WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
- irq_start);
- irq_base = irq_start;
+
+ if (of_property_read_u32(node, "routable_irqs", &nr_routable_irqs)) {
+ irq_base = irq_alloc_descs(irq_start, 16, gic_irqs,
+ numa_node_id());
+ if (IS_ERR_VALUE(irq_base)) {
+ WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+ irq_start);
+ irq_base = irq_start;
+ }
+
+ gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
+ hwirq_base, &gic_irq_domain_ops, gic);
+ } else {
+ if (WARN_ON(!gic_routable_irq_domain_ops))
+ return;
+
+ gic->domain = irq_domain_add_linear(node, nr_routable_irqs,
+ &gic_irq_domain_ops,
+ gic);
}
- gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
- hwirq_base, &gic_irq_domain_ops, gic);
+
if (WARN_ON(!gic->domain))
return;
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3e203eb..fd4192a 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -73,6 +73,12 @@ static inline void gic_init(unsigned int nr, int start,
gic_init_bases(nr, start, dist, cpu, 0, NULL);
}
-#endif /* __ASSEMBLY */
+extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
+static inline void __init register_routable_domain_ops
+ (const struct irq_domain_ops *ops)
+{
+ gic_routable_irq_domain_ops = ops;
+}
+#endif /* __ASSEMBLY */
#endif
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
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 <tglx@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 5 +++
arch/arm/boot/dts/dra7.dtsi | 1 +
drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
include/linux/irqchip/arm-gic.h | 8 +++-
4 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0..2d8c680 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.
+- 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 at fff11000 {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..b35cb12 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -55,6 +55,7 @@
compatible = "arm,cortex-a15-gic";
interrupt-controller;
#interrupt-cells = <3>;
+ routable_irqs = <160>;
reg = <0x48211000 0x1000>,
<0x48212000 0x1000>;
};
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 1760ceb..c5778ab 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -72,6 +72,8 @@ struct gic_chip_data {
static DEFINE_RAW_SPINLOCK(irq_controller_lock);
+const struct irq_domain_ops *gic_routable_irq_domain_ops;
+
/*
* The GIC mapping of CPU interfaces does not necessarily match
* the logical CPU numbering. Let's use a mapping as returned
@@ -675,11 +677,26 @@ 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);
+
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->map)
+ 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)
+{
+ irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
+
+ if (hw > 32) {
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->unmap)
+ 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,
@@ -694,8 +711,15 @@ 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]) {
+ if (gic_routable_irq_domain_ops &&
+ gic_routable_irq_domain_ops->xlate)
+ *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
+ controller, intspec, intsize,
+ out_hwirq, out_type);
+ else
+ *out_hwirq += 16;
+ }
*out_type = intspec[2] & IRQ_TYPE_SENSE_MASK;
return 0;
@@ -722,6 +746,7 @@ static struct notifier_block __cpuinitdata 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,
};
@@ -732,6 +757,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
int gic_irqs, irq_base, i;
+ int nr_routable_irqs;
BUG_ON(gic_nr >= MAX_GIC_NR);
@@ -797,14 +823,27 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start,
gic->gic_irqs = gic_irqs;
gic_irqs -= hwirq_base; /* calculate # of irqs to allocate */
- irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
- if (IS_ERR_VALUE(irq_base)) {
- WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
- irq_start);
- irq_base = irq_start;
+
+ if (of_property_read_u32(node, "routable_irqs", &nr_routable_irqs)) {
+ irq_base = irq_alloc_descs(irq_start, 16, gic_irqs,
+ numa_node_id());
+ if (IS_ERR_VALUE(irq_base)) {
+ WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+ irq_start);
+ irq_base = irq_start;
+ }
+
+ gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
+ hwirq_base, &gic_irq_domain_ops, gic);
+ } else {
+ if (WARN_ON(!gic_routable_irq_domain_ops))
+ return;
+
+ gic->domain = irq_domain_add_linear(node, nr_routable_irqs,
+ &gic_irq_domain_ops,
+ gic);
}
- gic->domain = irq_domain_add_legacy(node, gic_irqs, irq_base,
- hwirq_base, &gic_irq_domain_ops, gic);
+
if (WARN_ON(!gic->domain))
return;
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 3e203eb..fd4192a 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -73,6 +73,12 @@ static inline void gic_init(unsigned int nr, int start,
gic_init_bases(nr, start, dist, cpu, 0, NULL);
}
-#endif /* __ASSEMBLY */
+extern const struct irq_domain_ops *gic_routable_irq_domain_ops;
+static inline void __init register_routable_domain_ops
+ (const struct irq_domain_ops *ops)
+{
+ gic_routable_irq_domain_ops = ops;
+}
+#endif /* __ASSEMBLY */
#endif
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-09-30 13:59 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
This driver takes care a allocating a free irq and then configuring the
crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
be called right before the irqchip_init, so that it is setup to handle the
irqchip callbacks.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
.../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
include/linux/irqchip/irq-crossbar.h | 11 ++
5 files changed, 242 insertions(+)
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
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 0000000..cdec2cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,27 @@
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be "ti,irq-crossbar"
+- reg: Base address and the size of the crossbar registers.
+- max-irqs: Total number of irqs available at the interrupt controller.
+- reg-size: Size of a individual register in bytes. Every individual
+ register is assumed to be of same size. Valid sizes are 1, 2, 4.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+ crossbar. These interrupt lines are reserved in the soc,
+ so crossbar bar driver should not consider them as free
+ lines.
+
+Examples:
+ crossbar_mpu: @4a020000 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ max-irqs = <160>;
+ reg-size = <2>;
+ irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..ed6ced28 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -41,3 +41,11 @@ config VERSATILE_FPGA_IRQ_NR
int
default 4
depends on VERSATILE_FPGA_IRQ
+
+config IRQ_CROSSBAR
+ bool
+ help
+ Support for a CROSSBAR ip that preceeds the main interrupt controller.
+ The primary irqchip invokes the crossbar's callback which inturn allocates
+ a free irq and configures the IP. Thus the peripheral interrupts are
+ routed to one of the free irqchip interrupt lines.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index cda4cb5..7f690b7 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_RENESAS_INTC_IRQPIN) += irq-renesas-intc-irqpin.o
obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
+obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
new file mode 100644
index 0000000..3e1b488
--- /dev/null
+++ b/drivers/irqchip/irq-crossbar.c
@@ -0,0 +1,195 @@
+/*
+ * drivers/irqchip/irq-crossbar.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/slab.h>
+#include <linux/irqchip/arm-gic.h>
+
+#define IRQ_FREE -1
+#define GIC_IRQ_START 32
+
+/*
+ * @int_max: maximum number of supported interrupts
+ * @irq_map: array of interrupts to crossbar number mapping
+ * @crossbar_base: crossbar base address
+ * @register_offsets: offsets for each irq number
+ */
+struct crossbar_device {
+ uint int_max;
+ uint *irq_map;
+ void __iomem *crossbar_base;
+ int *register_offsets;
+ void (*write) (int, int);
+};
+
+static struct crossbar_device *cb;
+
+static inline void crossbar_writel(int irq_no, int cb_no)
+{
+ writel(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writew(int irq_no, int cb_no)
+{
+ writew(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writeb(int irq_no, int cb_no)
+{
+ writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline const u32 allocate_free_irq(int cb_no)
+{
+ int i;
+
+ for (i = 0; i < cb->int_max; i++) {
+ if (cb->irq_map[i] == IRQ_FREE) {
+ cb->irq_map[i] = cb_no;
+ return i;
+ }
+ }
+
+ return -ENODEV;
+}
+
+static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
+ return 0;
+}
+
+static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+ irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq - GIC_IRQ_START;
+ cb->irq_map[hw] = IRQ_FREE;
+}
+
+static int crossbar_domain_xlate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
+}
+
+const struct irq_domain_ops routable_irq_domain_ops = {
+ .map = crossbar_domain_map,
+ .unmap = crossbar_domain_unmap,
+ .xlate = crossbar_domain_xlate
+};
+
+static int __init crossbar_of_init(struct device_node *node)
+{
+ int i, size, max, reserved = 0, entry;
+ const __be32 *irqsr;
+
+ cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
+
+ if (!cb)
+ return -ENOMEM;
+
+ cb->crossbar_base = of_iomap(node, 0);
+ if (!cb->crossbar_base)
+ goto err1;
+
+ of_property_read_u32(node, "max-irqs", &max);
+ cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+ if (!cb->irq_map)
+ goto err2;
+
+ cb->int_max = max;
+
+ for (i = 0; i < max; i++)
+ cb->irq_map[i] = IRQ_FREE;
+
+ /* Get and mark reserved irqs */
+ irqsr = of_get_property(node, "irqs-reserved", &size);
+ if (irqsr) {
+ size /= sizeof(__be32);
+
+ for (i = 0; i < size; i++) {
+ entry = be32_to_cpup(irqsr + i);
+ if (entry > max) {
+ pr_err("Invalid reserved entry\n");
+ goto err3;
+ }
+ cb->irq_map[entry] = 0;
+ }
+ }
+
+ cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+ if (!cb->register_offsets)
+ goto err3;
+
+ of_property_read_u32(node, "reg-size", &size);
+
+ switch (size) {
+ case 1:
+ cb->write = crossbar_writeb;
+ break;
+ case 2:
+ cb->write = crossbar_writew;
+ break;
+ case 4:
+ cb->write = crossbar_writel;
+ break;
+ default:
+ pr_err("Invalid reg-size property\n");
+ goto err4;
+ break;
+ }
+
+ /*
+ * Register offsets are not linear because of the
+ * reserved irqs. so find and store the offsets once.
+ */
+ for (i = 0; i < max; i++) {
+ if (!cb->irq_map[i])
+ continue;
+
+ cb->register_offsets[i] = reserved;
+ reserved += size;
+ }
+
+ register_routable_domain_ops(&routable_irq_domain_ops);
+ return 0;
+
+err4:
+ kfree(cb->register_offsets);
+err3:
+ kfree(cb->irq_map);
+err2:
+ iounmap(cb->crossbar_base);
+err1:
+ kfree(cb);
+ return -ENOMEM;
+}
+
+static const struct of_device_id crossbar_match[] __initconst = {
+ { .compatible = "ti,irq-crossbar" },
+ {}
+};
+
+int crossbar_init(void)
+{
+ struct device_node *np;
+ np = of_find_matching_node(NULL, crossbar_match);
+ if (!np)
+ return -ENODEV;
+
+ crossbar_of_init(np);
+ return 0;
+}
diff --git a/include/linux/irqchip/irq-crossbar.h b/include/linux/irqchip/irq-crossbar.h
new file mode 100644
index 0000000..ad2f744
--- /dev/null
+++ b/include/linux/irqchip/irq-crossbar.h
@@ -0,0 +1,11 @@
+/*
+ * drivers/irqchip/irq-crossbar.h
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+int crossbar_init(void);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
This driver takes care a allocating a free irq and then configuring the
crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
be called right before the irqchip_init, so that it is setup to handle the
irqchip callbacks.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
.../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
include/linux/irqchip/irq-crossbar.h | 11 ++
5 files changed, 242 insertions(+)
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
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 0000000..cdec2cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,27 @@
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be "ti,irq-crossbar"
+- reg: Base address and the size of the crossbar registers.
+- max-irqs: Total number of irqs available at the interrupt controller.
+- reg-size: Size of a individual register in bytes. Every individual
+ register is assumed to be of same size. Valid sizes are 1, 2, 4.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+ crossbar. These interrupt lines are reserved in the soc,
+ so crossbar bar driver should not consider them as free
+ lines.
+
+Examples:
+ crossbar_mpu: @4a020000 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ max-irqs = <160>;
+ reg-size = <2>;
+ irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..ed6ced28 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -41,3 +41,11 @@ config VERSATILE_FPGA_IRQ_NR
int
default 4
depends on VERSATILE_FPGA_IRQ
+
+config IRQ_CROSSBAR
+ bool
+ help
+ Support for a CROSSBAR ip that preceeds the main interrupt controller.
+ The primary irqchip invokes the crossbar's callback which inturn allocates
+ a free irq and configures the IP. Thus the peripheral interrupts are
+ routed to one of the free irqchip interrupt lines.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index cda4cb5..7f690b7 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_RENESAS_INTC_IRQPIN) += irq-renesas-intc-irqpin.o
obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
+obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
new file mode 100644
index 0000000..3e1b488
--- /dev/null
+++ b/drivers/irqchip/irq-crossbar.c
@@ -0,0 +1,195 @@
+/*
+ * drivers/irqchip/irq-crossbar.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/slab.h>
+#include <linux/irqchip/arm-gic.h>
+
+#define IRQ_FREE -1
+#define GIC_IRQ_START 32
+
+/*
+ * @int_max: maximum number of supported interrupts
+ * @irq_map: array of interrupts to crossbar number mapping
+ * @crossbar_base: crossbar base address
+ * @register_offsets: offsets for each irq number
+ */
+struct crossbar_device {
+ uint int_max;
+ uint *irq_map;
+ void __iomem *crossbar_base;
+ int *register_offsets;
+ void (*write) (int, int);
+};
+
+static struct crossbar_device *cb;
+
+static inline void crossbar_writel(int irq_no, int cb_no)
+{
+ writel(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writew(int irq_no, int cb_no)
+{
+ writew(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writeb(int irq_no, int cb_no)
+{
+ writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline const u32 allocate_free_irq(int cb_no)
+{
+ int i;
+
+ for (i = 0; i < cb->int_max; i++) {
+ if (cb->irq_map[i] == IRQ_FREE) {
+ cb->irq_map[i] = cb_no;
+ return i;
+ }
+ }
+
+ return -ENODEV;
+}
+
+static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
+ return 0;
+}
+
+static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+ irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq - GIC_IRQ_START;
+ cb->irq_map[hw] = IRQ_FREE;
+}
+
+static int crossbar_domain_xlate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
+}
+
+const struct irq_domain_ops routable_irq_domain_ops = {
+ .map = crossbar_domain_map,
+ .unmap = crossbar_domain_unmap,
+ .xlate = crossbar_domain_xlate
+};
+
+static int __init crossbar_of_init(struct device_node *node)
+{
+ int i, size, max, reserved = 0, entry;
+ const __be32 *irqsr;
+
+ cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
+
+ if (!cb)
+ return -ENOMEM;
+
+ cb->crossbar_base = of_iomap(node, 0);
+ if (!cb->crossbar_base)
+ goto err1;
+
+ of_property_read_u32(node, "max-irqs", &max);
+ cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+ if (!cb->irq_map)
+ goto err2;
+
+ cb->int_max = max;
+
+ for (i = 0; i < max; i++)
+ cb->irq_map[i] = IRQ_FREE;
+
+ /* Get and mark reserved irqs */
+ irqsr = of_get_property(node, "irqs-reserved", &size);
+ if (irqsr) {
+ size /= sizeof(__be32);
+
+ for (i = 0; i < size; i++) {
+ entry = be32_to_cpup(irqsr + i);
+ if (entry > max) {
+ pr_err("Invalid reserved entry\n");
+ goto err3;
+ }
+ cb->irq_map[entry] = 0;
+ }
+ }
+
+ cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+ if (!cb->register_offsets)
+ goto err3;
+
+ of_property_read_u32(node, "reg-size", &size);
+
+ switch (size) {
+ case 1:
+ cb->write = crossbar_writeb;
+ break;
+ case 2:
+ cb->write = crossbar_writew;
+ break;
+ case 4:
+ cb->write = crossbar_writel;
+ break;
+ default:
+ pr_err("Invalid reg-size property\n");
+ goto err4;
+ break;
+ }
+
+ /*
+ * Register offsets are not linear because of the
+ * reserved irqs. so find and store the offsets once.
+ */
+ for (i = 0; i < max; i++) {
+ if (!cb->irq_map[i])
+ continue;
+
+ cb->register_offsets[i] = reserved;
+ reserved += size;
+ }
+
+ register_routable_domain_ops(&routable_irq_domain_ops);
+ return 0;
+
+err4:
+ kfree(cb->register_offsets);
+err3:
+ kfree(cb->irq_map);
+err2:
+ iounmap(cb->crossbar_base);
+err1:
+ kfree(cb);
+ return -ENOMEM;
+}
+
+static const struct of_device_id crossbar_match[] __initconst = {
+ { .compatible = "ti,irq-crossbar" },
+ {}
+};
+
+int crossbar_init(void)
+{
+ struct device_node *np;
+ np = of_find_matching_node(NULL, crossbar_match);
+ if (!np)
+ return -ENODEV;
+
+ crossbar_of_init(np);
+ return 0;
+}
diff --git a/include/linux/irqchip/irq-crossbar.h b/include/linux/irqchip/irq-crossbar.h
new file mode 100644
index 0000000..ad2f744
--- /dev/null
+++ b/include/linux/irqchip/irq-crossbar.h
@@ -0,0 +1,11 @@
+/*
+ * drivers/irqchip/irq-crossbar.h
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+int crossbar_init(void);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Some socs have a large number of interrupts requests to service
the needs of its many peripherals and subsystems. All of the
interrupt lines from the subsystems are not needed at the same
time, so they have to be muxed to the irq-controller appropriately.
In such places a interrupt controllers are preceded by an CROSSBAR
that provides flexibility in muxing the device requests to the controller
inputs.
This driver takes care a allocating a free irq and then configuring the
crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
be called right before the irqchip_init, so that it is setup to handle the
irqchip callbacks.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
.../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
include/linux/irqchip/irq-crossbar.h | 11 ++
5 files changed, 242 insertions(+)
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
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 0000000..cdec2cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,27 @@
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be "ti,irq-crossbar"
+- reg: Base address and the size of the crossbar registers.
+- max-irqs: Total number of irqs available at the interrupt controller.
+- reg-size: Size of a individual register in bytes. Every individual
+ register is assumed to be of same size. Valid sizes are 1, 2, 4.
+- irqs-reserved: List of the reserved irq lines that are not muxed using
+ crossbar. These interrupt lines are reserved in the soc,
+ so crossbar bar driver should not consider them as free
+ lines.
+
+Examples:
+ crossbar_mpu: @4a020000 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ max-irqs = <160>;
+ reg-size = <2>;
+ irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ };
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..ed6ced28 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -41,3 +41,11 @@ config VERSATILE_FPGA_IRQ_NR
int
default 4
depends on VERSATILE_FPGA_IRQ
+
+config IRQ_CROSSBAR
+ bool
+ help
+ Support for a CROSSBAR ip that preceeds the main interrupt controller.
+ The primary irqchip invokes the crossbar's callback which inturn allocates
+ a free irq and configures the IP. Thus the peripheral interrupts are
+ routed to one of the free irqchip interrupt lines.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index cda4cb5..7f690b7 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_RENESAS_INTC_IRQPIN) += irq-renesas-intc-irqpin.o
obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
+obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
new file mode 100644
index 0000000..3e1b488
--- /dev/null
+++ b/drivers/irqchip/irq-crossbar.c
@@ -0,0 +1,195 @@
+/*
+ * drivers/irqchip/irq-crossbar.c
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/slab.h>
+#include <linux/irqchip/arm-gic.h>
+
+#define IRQ_FREE -1
+#define GIC_IRQ_START 32
+
+/*
+ * @int_max: maximum number of supported interrupts
+ * @irq_map: array of interrupts to crossbar number mapping
+ * @crossbar_base: crossbar base address
+ * @register_offsets: offsets for each irq number
+ */
+struct crossbar_device {
+ uint int_max;
+ uint *irq_map;
+ void __iomem *crossbar_base;
+ int *register_offsets;
+ void (*write) (int, int);
+};
+
+static struct crossbar_device *cb;
+
+static inline void crossbar_writel(int irq_no, int cb_no)
+{
+ writel(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writew(int irq_no, int cb_no)
+{
+ writew(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline void crossbar_writeb(int irq_no, int cb_no)
+{
+ writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
+}
+
+static inline const u32 allocate_free_irq(int cb_no)
+{
+ int i;
+
+ for (i = 0; i < cb->int_max; i++) {
+ if (cb->irq_map[i] == IRQ_FREE) {
+ cb->irq_map[i] = cb_no;
+ return i;
+ }
+ }
+
+ return -ENODEV;
+}
+
+static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
+ irq_hw_number_t hw)
+{
+ cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
+ return 0;
+}
+
+static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
+{
+ irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq - GIC_IRQ_START;
+ cb->irq_map[hw] = IRQ_FREE;
+}
+
+static int crossbar_domain_xlate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
+}
+
+const struct irq_domain_ops routable_irq_domain_ops = {
+ .map = crossbar_domain_map,
+ .unmap = crossbar_domain_unmap,
+ .xlate = crossbar_domain_xlate
+};
+
+static int __init crossbar_of_init(struct device_node *node)
+{
+ int i, size, max, reserved = 0, entry;
+ const __be32 *irqsr;
+
+ cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
+
+ if (!cb)
+ return -ENOMEM;
+
+ cb->crossbar_base = of_iomap(node, 0);
+ if (!cb->crossbar_base)
+ goto err1;
+
+ of_property_read_u32(node, "max-irqs", &max);
+ cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+ if (!cb->irq_map)
+ goto err2;
+
+ cb->int_max = max;
+
+ for (i = 0; i < max; i++)
+ cb->irq_map[i] = IRQ_FREE;
+
+ /* Get and mark reserved irqs */
+ irqsr = of_get_property(node, "irqs-reserved", &size);
+ if (irqsr) {
+ size /= sizeof(__be32);
+
+ for (i = 0; i < size; i++) {
+ entry = be32_to_cpup(irqsr + i);
+ if (entry > max) {
+ pr_err("Invalid reserved entry\n");
+ goto err3;
+ }
+ cb->irq_map[entry] = 0;
+ }
+ }
+
+ cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+ if (!cb->register_offsets)
+ goto err3;
+
+ of_property_read_u32(node, "reg-size", &size);
+
+ switch (size) {
+ case 1:
+ cb->write = crossbar_writeb;
+ break;
+ case 2:
+ cb->write = crossbar_writew;
+ break;
+ case 4:
+ cb->write = crossbar_writel;
+ break;
+ default:
+ pr_err("Invalid reg-size property\n");
+ goto err4;
+ break;
+ }
+
+ /*
+ * Register offsets are not linear because of the
+ * reserved irqs. so find and store the offsets once.
+ */
+ for (i = 0; i < max; i++) {
+ if (!cb->irq_map[i])
+ continue;
+
+ cb->register_offsets[i] = reserved;
+ reserved += size;
+ }
+
+ register_routable_domain_ops(&routable_irq_domain_ops);
+ return 0;
+
+err4:
+ kfree(cb->register_offsets);
+err3:
+ kfree(cb->irq_map);
+err2:
+ iounmap(cb->crossbar_base);
+err1:
+ kfree(cb);
+ return -ENOMEM;
+}
+
+static const struct of_device_id crossbar_match[] __initconst = {
+ { .compatible = "ti,irq-crossbar" },
+ {}
+};
+
+int crossbar_init(void)
+{
+ struct device_node *np;
+ np = of_find_matching_node(NULL, crossbar_match);
+ if (!np)
+ return -ENODEV;
+
+ crossbar_of_init(np);
+ return 0;
+}
diff --git a/include/linux/irqchip/irq-crossbar.h b/include/linux/irqchip/irq-crossbar.h
new file mode 100644
index 0000000..ad2f744
--- /dev/null
+++ b/include/linux/irqchip/irq-crossbar.h
@@ -0,0 +1,11 @@
+/*
+ * drivers/irqchip/irq-crossbar.h
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+int crossbar_init(void);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 3/6] ARM: DTS: DRA: Add crossbar device binding
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-09-30 13:59 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland, Benoit Cousson
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b35cb12..799b7be 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -492,5 +492,14 @@
dmas = <&sdma 70>, <&sdma 71>;
dma-names = "tx0", "rx0";
};
+
+ crossbar_mpu: @4a020000 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ max-irqs = <160>;
+ reg-size = <2>;
+ irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ };
+
};
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 3/6] ARM: DTS: DRA: Add crossbar device binding
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland, Benoit Cousson
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b35cb12..799b7be 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -492,5 +492,14 @@
dmas = <&sdma 70>, <&sdma 71>;
dma-names = "tx0", "rx0";
};
+
+ crossbar_mpu: @4a020000 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ max-irqs = <160>;
+ reg-size = <2>;
+ irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ };
+
};
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 3/6] ARM: DTS: DRA: Add crossbar device binding
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
This adds the irq crossbar device node.
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index b35cb12..799b7be 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -492,5 +492,14 @@
dmas = <&sdma 70>, <&sdma 71>;
dma-names = "tx0", "rx0";
};
+
+ crossbar_mpu: @4a020000 {
+ compatible = "ti,irq-crossbar";
+ reg = <0x4a002a48 0x130>;
+ max-irqs = <160>;
+ reg-size = <2>;
+ irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+ };
+
};
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 4/6] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs.
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland, Benoit Cousson
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 88 +++++++++++++++++++++----------------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 799b7be..bef1c99 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -104,10 +104,10 @@
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
- interrupts = <0 12 0x4>,
- <0 13 0x4>,
- <0 14 0x4>,
- <0 15 0x4>;
+ interrupts = <0 7 0x4>,
+ <0 8 0x4>,
+ <0 9 0x4>,
+ <0 10 0x4>;
#dma-cells = <1>;
#dma-channels = <32>;
#dma-requests = <127>;
@@ -116,7 +116,7 @@
gpio1: gpio@4ae10000 {
compatible = "ti,omap4-gpio";
reg = <0x4ae10000 0x200>;
- interrupts = <0 29 0x4>;
+ interrupts = <0 24 0x4>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -127,7 +127,7 @@
gpio2: gpio@48055000 {
compatible = "ti,omap4-gpio";
reg = <0x48055000 0x200>;
- interrupts = <0 30 0x4>;
+ interrupts = <0 25 0x4>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -138,7 +138,7 @@
gpio3: gpio@48057000 {
compatible = "ti,omap4-gpio";
reg = <0x48057000 0x200>;
- interrupts = <0 31 0x4>;
+ interrupts = <0 26 0x4>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -149,7 +149,7 @@
gpio4: gpio@48059000 {
compatible = "ti,omap4-gpio";
reg = <0x48059000 0x200>;
- interrupts = <0 32 0x4>;
+ interrupts = <0 27 0x4>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -160,7 +160,7 @@
gpio5: gpio@4805b000 {
compatible = "ti,omap4-gpio";
reg = <0x4805b000 0x200>;
- interrupts = <0 33 0x4>;
+ interrupts = <0 28 0x4>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -171,7 +171,7 @@
gpio6: gpio@4805d000 {
compatible = "ti,omap4-gpio";
reg = <0x4805d000 0x200>;
- interrupts = <0 34 0x4>;
+ interrupts = <0 29 0x4>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -182,7 +182,7 @@
gpio7: gpio@48051000 {
compatible = "ti,omap4-gpio";
reg = <0x48051000 0x200>;
- interrupts = <0 35 0x4>;
+ interrupts = <0 30 0x4>;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -193,7 +193,7 @@
gpio8: gpio@48053000 {
compatible = "ti,omap4-gpio";
reg = <0x48053000 0x200>;
- interrupts = <0 121 0x4>;
+ interrupts = <0 116 0x4>;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
@@ -204,7 +204,7 @@
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
- interrupts = <0 72 0x4>;
+ interrupts = <0 67 0x4>;
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
@@ -212,7 +212,7 @@
uart2: serial@4806c000 {
compatible = "ti,omap4-uart";
reg = <0x4806c000 0x100>;
- interrupts = <0 73 0x4>;
+ interrupts = <0 68 0x4>;
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
@@ -220,7 +220,7 @@
uart3: serial@48020000 {
compatible = "ti,omap4-uart";
reg = <0x48020000 0x100>;
- interrupts = <0 74 0x4>;
+ interrupts = <0 69 0x4>;
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
@@ -228,7 +228,7 @@
uart4: serial@4806e000 {
compatible = "ti,omap4-uart";
reg = <0x4806e000 0x100>;
- interrupts = <0 70 0x4>;
+ interrupts = <0 65 0x4>;
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
@@ -236,7 +236,7 @@
uart5: serial@48066000 {
compatible = "ti,omap4-uart";
reg = <0x48066000 0x100>;
- interrupts = <0 105 0x4>;
+ interrupts = <0 100 0x4>;
ti,hwmods = "uart5";
clock-frequency = <48000000>;
};
@@ -244,7 +244,7 @@
uart6: serial@48068000 {
compatible = "ti,omap4-uart";
reg = <0x48068000 0x100>;
- interrupts = <0 106 0x4>;
+ interrupts = <0 101 0x4>;
ti,hwmods = "uart6";
clock-frequency = <48000000>;
};
@@ -252,7 +252,7 @@
timer1: timer@4ae18000 {
compatible = "ti,omap5430-timer";
reg = <0x4ae18000 0x80>;
- interrupts = <0 37 0x4>;
+ interrupts = <0 32 0x4>;
ti,hwmods = "timer1";
ti,timer-alwon;
};
@@ -260,28 +260,28 @@
timer2: timer@48032000 {
compatible = "ti,omap5430-timer";
reg = <0x48032000 0x80>;
- interrupts = <0 38 0x4>;
+ interrupts = <0 33 0x4>;
ti,hwmods = "timer2";
};
timer3: timer@48034000 {
compatible = "ti,omap5430-timer";
reg = <0x48034000 0x80>;
- interrupts = <0 39 0x4>;
+ interrupts = <0 34 0x4>;
ti,hwmods = "timer3";
};
timer4: timer@48036000 {
compatible = "ti,omap5430-timer";
reg = <0x48036000 0x80>;
- interrupts = <0 40 0x4>;
+ interrupts = <0 35 0x4>;
ti,hwmods = "timer4";
};
timer5: timer@48820000 {
compatible = "ti,omap5430-timer";
reg = <0x48820000 0x80>;
- interrupts = <0 41 0x4>;
+ interrupts = <0 36 0x4>;
ti,hwmods = "timer5";
ti,timer-dsp;
};
@@ -289,7 +289,7 @@
timer6: timer@48822000 {
compatible = "ti,omap5430-timer";
reg = <0x48822000 0x80>;
- interrupts = <0 42 0x4>;
+ interrupts = <0 37 0x4>;
ti,hwmods = "timer6";
ti,timer-dsp;
ti,timer-pwm;
@@ -298,7 +298,7 @@
timer7: timer@48824000 {
compatible = "ti,omap5430-timer";
reg = <0x48824000 0x80>;
- interrupts = <0 43 0x4>;
+ interrupts = <0 38 0x4>;
ti,hwmods = "timer7";
ti,timer-dsp;
};
@@ -306,7 +306,7 @@
timer8: timer@48826000 {
compatible = "ti,omap5430-timer";
reg = <0x48826000 0x80>;
- interrupts = <0 44 0x4>;
+ interrupts = <0 39 0x4>;
ti,hwmods = "timer8";
ti,timer-dsp;
ti,timer-pwm;
@@ -315,21 +315,21 @@
timer9: timer@4803e000 {
compatible = "ti,omap5430-timer";
reg = <0x4803e000 0x80>;
- interrupts = <0 45 0x4>;
+ interrupts = <0 40 0x4>;
ti,hwmods = "timer9";
};
timer10: timer@48086000 {
compatible = "ti,omap5430-timer";
reg = <0x48086000 0x80>;
- interrupts = <0 46 0x4>;
+ interrupts = <0 41 0x4>;
ti,hwmods = "timer10";
};
timer11: timer@48088000 {
compatible = "ti,omap5430-timer";
reg = <0x48088000 0x80>;
- interrupts = <0 47 0x4>;
+ interrupts = <0 42 0x4>;
ti,hwmods = "timer11";
ti,timer-pwm;
};
@@ -337,21 +337,21 @@
wdt2: wdt@4ae14000 {
compatible = "ti,omap4-wdt";
reg = <0x4ae14000 0x80>;
- interrupts = <0 80 0x4>;
+ interrupts = <0 75 0x4>;
ti,hwmods = "wd_timer2";
};
dmm: dmm@4e000000 {
compatible = "ti,omap5-dmm";
reg = <0x4e000000 0x800>;
- interrupts = <0 113 0x4>;
+ interrupts = <0 108 0x4>;
ti,hwmods = "dmm";
};
i2c1: i2c@48070000 {
compatible = "ti,omap4-i2c";
reg = <0x48070000 0x100>;
- interrupts = <0 56 0x4>;
+ interrupts = <0 51 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
@@ -360,7 +360,7 @@
i2c2: i2c@48072000 {
compatible = "ti,omap4-i2c";
reg = <0x48072000 0x100>;
- interrupts = <0 57 0x4>;
+ interrupts = <0 52 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
@@ -369,7 +369,7 @@
i2c3: i2c@48060000 {
compatible = "ti,omap4-i2c";
reg = <0x48060000 0x100>;
- interrupts = <0 61 0x4>;
+ interrupts = <0 56 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
@@ -378,7 +378,7 @@
i2c4: i2c@4807a000 {
compatible = "ti,omap4-i2c";
reg = <0x4807a000 0x100>;
- interrupts = <0 62 0x4>;
+ interrupts = <0 57 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c4";
@@ -387,7 +387,7 @@
i2c5: i2c@4807c000 {
compatible = "ti,omap4-i2c";
reg = <0x4807c000 0x100>;
- interrupts = <0 60 0x4>;
+ interrupts = <0 55 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c5";
@@ -396,7 +396,7 @@
mmc1: mmc@4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
- interrupts = <0 83 0x4>;
+ interrupts = <0 78 0x4>;
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
@@ -407,7 +407,7 @@
mmc2: mmc@480b4000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480b4000 0x400>;
- interrupts = <0 86 0x4>;
+ interrupts = <0 81 0x4>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
dmas = <&sdma 47>, <&sdma 48>;
@@ -417,7 +417,7 @@
mmc3: mmc@480ad000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480ad000 0x400>;
- interrupts = <0 94 0x4>;
+ interrupts = <0 89 0x4>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
dmas = <&sdma 77>, <&sdma 78>;
@@ -427,7 +427,7 @@
mmc4: mmc@480d1000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480d1000 0x400>;
- interrupts = <0 96 0x4>;
+ interrupts = <0 91 0x4>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
dmas = <&sdma 57>, <&sdma 58>;
@@ -437,7 +437,7 @@
mcspi1: spi@48098000 {
compatible = "ti,omap4-mcspi";
reg = <0x48098000 0x200>;
- interrupts = <0 65 0x4>;
+ interrupts = <0 60 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi1";
@@ -457,7 +457,7 @@
mcspi2: spi@4809a000 {
compatible = "ti,omap4-mcspi";
reg = <0x4809a000 0x200>;
- interrupts = <0 66 0x4>;
+ interrupts = <0 61 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi2";
@@ -472,7 +472,7 @@
mcspi3: spi@480b8000 {
compatible = "ti,omap4-mcspi";
reg = <0x480b8000 0x200>;
- interrupts = <0 91 0x4>;
+ interrupts = <0 86 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi3";
@@ -484,7 +484,7 @@
mcspi4: spi@480ba000 {
compatible = "ti,omap4-mcspi";
reg = <0x480ba000 0x200>;
- interrupts = <0 48 0x4>;
+ interrupts = <0 43 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi4";
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 4/6] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs.
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA
Cc: tglx-hfZtesqFncYOwBW4kG4KsQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
santosh.shilimkar-l0cyMroinI0, linux-lFZ/pmaqli7XmaaqVzeoHQ,
tony-4v6yS6AI5VpBDgjK7y7TUQ, rnayak-l0cyMroinI0,
marc.zyngier-5wv7dgnIgG8, r.sricharan-l0cyMroinI0,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, mark.rutland-5wv7dgnIgG8,
Benoit Cousson
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Cc: Benoit Cousson <bcousson-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
Cc: Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>
Cc: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Sricharan R <r.sricharan-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/dra7.dtsi | 88 +++++++++++++++++++++----------------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 799b7be..bef1c99 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -104,10 +104,10 @@
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
- interrupts = <0 12 0x4>,
- <0 13 0x4>,
- <0 14 0x4>,
- <0 15 0x4>;
+ interrupts = <0 7 0x4>,
+ <0 8 0x4>,
+ <0 9 0x4>,
+ <0 10 0x4>;
#dma-cells = <1>;
#dma-channels = <32>;
#dma-requests = <127>;
@@ -116,7 +116,7 @@
gpio1: gpio@4ae10000 {
compatible = "ti,omap4-gpio";
reg = <0x4ae10000 0x200>;
- interrupts = <0 29 0x4>;
+ interrupts = <0 24 0x4>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -127,7 +127,7 @@
gpio2: gpio@48055000 {
compatible = "ti,omap4-gpio";
reg = <0x48055000 0x200>;
- interrupts = <0 30 0x4>;
+ interrupts = <0 25 0x4>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -138,7 +138,7 @@
gpio3: gpio@48057000 {
compatible = "ti,omap4-gpio";
reg = <0x48057000 0x200>;
- interrupts = <0 31 0x4>;
+ interrupts = <0 26 0x4>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -149,7 +149,7 @@
gpio4: gpio@48059000 {
compatible = "ti,omap4-gpio";
reg = <0x48059000 0x200>;
- interrupts = <0 32 0x4>;
+ interrupts = <0 27 0x4>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -160,7 +160,7 @@
gpio5: gpio@4805b000 {
compatible = "ti,omap4-gpio";
reg = <0x4805b000 0x200>;
- interrupts = <0 33 0x4>;
+ interrupts = <0 28 0x4>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -171,7 +171,7 @@
gpio6: gpio@4805d000 {
compatible = "ti,omap4-gpio";
reg = <0x4805d000 0x200>;
- interrupts = <0 34 0x4>;
+ interrupts = <0 29 0x4>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -182,7 +182,7 @@
gpio7: gpio@48051000 {
compatible = "ti,omap4-gpio";
reg = <0x48051000 0x200>;
- interrupts = <0 35 0x4>;
+ interrupts = <0 30 0x4>;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -193,7 +193,7 @@
gpio8: gpio@48053000 {
compatible = "ti,omap4-gpio";
reg = <0x48053000 0x200>;
- interrupts = <0 121 0x4>;
+ interrupts = <0 116 0x4>;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
@@ -204,7 +204,7 @@
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
- interrupts = <0 72 0x4>;
+ interrupts = <0 67 0x4>;
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
@@ -212,7 +212,7 @@
uart2: serial@4806c000 {
compatible = "ti,omap4-uart";
reg = <0x4806c000 0x100>;
- interrupts = <0 73 0x4>;
+ interrupts = <0 68 0x4>;
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
@@ -220,7 +220,7 @@
uart3: serial@48020000 {
compatible = "ti,omap4-uart";
reg = <0x48020000 0x100>;
- interrupts = <0 74 0x4>;
+ interrupts = <0 69 0x4>;
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
@@ -228,7 +228,7 @@
uart4: serial@4806e000 {
compatible = "ti,omap4-uart";
reg = <0x4806e000 0x100>;
- interrupts = <0 70 0x4>;
+ interrupts = <0 65 0x4>;
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
@@ -236,7 +236,7 @@
uart5: serial@48066000 {
compatible = "ti,omap4-uart";
reg = <0x48066000 0x100>;
- interrupts = <0 105 0x4>;
+ interrupts = <0 100 0x4>;
ti,hwmods = "uart5";
clock-frequency = <48000000>;
};
@@ -244,7 +244,7 @@
uart6: serial@48068000 {
compatible = "ti,omap4-uart";
reg = <0x48068000 0x100>;
- interrupts = <0 106 0x4>;
+ interrupts = <0 101 0x4>;
ti,hwmods = "uart6";
clock-frequency = <48000000>;
};
@@ -252,7 +252,7 @@
timer1: timer@4ae18000 {
compatible = "ti,omap5430-timer";
reg = <0x4ae18000 0x80>;
- interrupts = <0 37 0x4>;
+ interrupts = <0 32 0x4>;
ti,hwmods = "timer1";
ti,timer-alwon;
};
@@ -260,28 +260,28 @@
timer2: timer@48032000 {
compatible = "ti,omap5430-timer";
reg = <0x48032000 0x80>;
- interrupts = <0 38 0x4>;
+ interrupts = <0 33 0x4>;
ti,hwmods = "timer2";
};
timer3: timer@48034000 {
compatible = "ti,omap5430-timer";
reg = <0x48034000 0x80>;
- interrupts = <0 39 0x4>;
+ interrupts = <0 34 0x4>;
ti,hwmods = "timer3";
};
timer4: timer@48036000 {
compatible = "ti,omap5430-timer";
reg = <0x48036000 0x80>;
- interrupts = <0 40 0x4>;
+ interrupts = <0 35 0x4>;
ti,hwmods = "timer4";
};
timer5: timer@48820000 {
compatible = "ti,omap5430-timer";
reg = <0x48820000 0x80>;
- interrupts = <0 41 0x4>;
+ interrupts = <0 36 0x4>;
ti,hwmods = "timer5";
ti,timer-dsp;
};
@@ -289,7 +289,7 @@
timer6: timer@48822000 {
compatible = "ti,omap5430-timer";
reg = <0x48822000 0x80>;
- interrupts = <0 42 0x4>;
+ interrupts = <0 37 0x4>;
ti,hwmods = "timer6";
ti,timer-dsp;
ti,timer-pwm;
@@ -298,7 +298,7 @@
timer7: timer@48824000 {
compatible = "ti,omap5430-timer";
reg = <0x48824000 0x80>;
- interrupts = <0 43 0x4>;
+ interrupts = <0 38 0x4>;
ti,hwmods = "timer7";
ti,timer-dsp;
};
@@ -306,7 +306,7 @@
timer8: timer@48826000 {
compatible = "ti,omap5430-timer";
reg = <0x48826000 0x80>;
- interrupts = <0 44 0x4>;
+ interrupts = <0 39 0x4>;
ti,hwmods = "timer8";
ti,timer-dsp;
ti,timer-pwm;
@@ -315,21 +315,21 @@
timer9: timer@4803e000 {
compatible = "ti,omap5430-timer";
reg = <0x4803e000 0x80>;
- interrupts = <0 45 0x4>;
+ interrupts = <0 40 0x4>;
ti,hwmods = "timer9";
};
timer10: timer@48086000 {
compatible = "ti,omap5430-timer";
reg = <0x48086000 0x80>;
- interrupts = <0 46 0x4>;
+ interrupts = <0 41 0x4>;
ti,hwmods = "timer10";
};
timer11: timer@48088000 {
compatible = "ti,omap5430-timer";
reg = <0x48088000 0x80>;
- interrupts = <0 47 0x4>;
+ interrupts = <0 42 0x4>;
ti,hwmods = "timer11";
ti,timer-pwm;
};
@@ -337,21 +337,21 @@
wdt2: wdt@4ae14000 {
compatible = "ti,omap4-wdt";
reg = <0x4ae14000 0x80>;
- interrupts = <0 80 0x4>;
+ interrupts = <0 75 0x4>;
ti,hwmods = "wd_timer2";
};
dmm: dmm@4e000000 {
compatible = "ti,omap5-dmm";
reg = <0x4e000000 0x800>;
- interrupts = <0 113 0x4>;
+ interrupts = <0 108 0x4>;
ti,hwmods = "dmm";
};
i2c1: i2c@48070000 {
compatible = "ti,omap4-i2c";
reg = <0x48070000 0x100>;
- interrupts = <0 56 0x4>;
+ interrupts = <0 51 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
@@ -360,7 +360,7 @@
i2c2: i2c@48072000 {
compatible = "ti,omap4-i2c";
reg = <0x48072000 0x100>;
- interrupts = <0 57 0x4>;
+ interrupts = <0 52 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
@@ -369,7 +369,7 @@
i2c3: i2c@48060000 {
compatible = "ti,omap4-i2c";
reg = <0x48060000 0x100>;
- interrupts = <0 61 0x4>;
+ interrupts = <0 56 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
@@ -378,7 +378,7 @@
i2c4: i2c@4807a000 {
compatible = "ti,omap4-i2c";
reg = <0x4807a000 0x100>;
- interrupts = <0 62 0x4>;
+ interrupts = <0 57 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c4";
@@ -387,7 +387,7 @@
i2c5: i2c@4807c000 {
compatible = "ti,omap4-i2c";
reg = <0x4807c000 0x100>;
- interrupts = <0 60 0x4>;
+ interrupts = <0 55 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c5";
@@ -396,7 +396,7 @@
mmc1: mmc@4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
- interrupts = <0 83 0x4>;
+ interrupts = <0 78 0x4>;
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
@@ -407,7 +407,7 @@
mmc2: mmc@480b4000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480b4000 0x400>;
- interrupts = <0 86 0x4>;
+ interrupts = <0 81 0x4>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
dmas = <&sdma 47>, <&sdma 48>;
@@ -417,7 +417,7 @@
mmc3: mmc@480ad000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480ad000 0x400>;
- interrupts = <0 94 0x4>;
+ interrupts = <0 89 0x4>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
dmas = <&sdma 77>, <&sdma 78>;
@@ -427,7 +427,7 @@
mmc4: mmc@480d1000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480d1000 0x400>;
- interrupts = <0 96 0x4>;
+ interrupts = <0 91 0x4>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
dmas = <&sdma 57>, <&sdma 58>;
@@ -437,7 +437,7 @@
mcspi1: spi@48098000 {
compatible = "ti,omap4-mcspi";
reg = <0x48098000 0x200>;
- interrupts = <0 65 0x4>;
+ interrupts = <0 60 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi1";
@@ -457,7 +457,7 @@
mcspi2: spi@4809a000 {
compatible = "ti,omap4-mcspi";
reg = <0x4809a000 0x200>;
- interrupts = <0 66 0x4>;
+ interrupts = <0 61 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi2";
@@ -472,7 +472,7 @@
mcspi3: spi@480b8000 {
compatible = "ti,omap4-mcspi";
reg = <0x480b8000 0x200>;
- interrupts = <0 91 0x4>;
+ interrupts = <0 86 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi3";
@@ -484,7 +484,7 @@
mcspi4: spi@480ba000 {
compatible = "ti,omap4-mcspi";
reg = <0x480ba000 0x200>;
- interrupts = <0 48 0x4>;
+ interrupts = <0 43 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi4";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 4/6] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs.
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Now with the crossbar IP in picture, the peripherals do not have the
fixed interrupt lines. Instead they rely on the crossbar irqchip to
allocate and map a free interrupt line to its crossbar input. So replacing
all the peripheral interrupt numbers with its fixed crossbar input lines.
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/boot/dts/dra7.dtsi | 88 +++++++++++++++++++++----------------------
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 799b7be..bef1c99 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -104,10 +104,10 @@
sdma: dma-controller at 4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
- interrupts = <0 12 0x4>,
- <0 13 0x4>,
- <0 14 0x4>,
- <0 15 0x4>;
+ interrupts = <0 7 0x4>,
+ <0 8 0x4>,
+ <0 9 0x4>,
+ <0 10 0x4>;
#dma-cells = <1>;
#dma-channels = <32>;
#dma-requests = <127>;
@@ -116,7 +116,7 @@
gpio1: gpio at 4ae10000 {
compatible = "ti,omap4-gpio";
reg = <0x4ae10000 0x200>;
- interrupts = <0 29 0x4>;
+ interrupts = <0 24 0x4>;
ti,hwmods = "gpio1";
gpio-controller;
#gpio-cells = <2>;
@@ -127,7 +127,7 @@
gpio2: gpio at 48055000 {
compatible = "ti,omap4-gpio";
reg = <0x48055000 0x200>;
- interrupts = <0 30 0x4>;
+ interrupts = <0 25 0x4>;
ti,hwmods = "gpio2";
gpio-controller;
#gpio-cells = <2>;
@@ -138,7 +138,7 @@
gpio3: gpio at 48057000 {
compatible = "ti,omap4-gpio";
reg = <0x48057000 0x200>;
- interrupts = <0 31 0x4>;
+ interrupts = <0 26 0x4>;
ti,hwmods = "gpio3";
gpio-controller;
#gpio-cells = <2>;
@@ -149,7 +149,7 @@
gpio4: gpio at 48059000 {
compatible = "ti,omap4-gpio";
reg = <0x48059000 0x200>;
- interrupts = <0 32 0x4>;
+ interrupts = <0 27 0x4>;
ti,hwmods = "gpio4";
gpio-controller;
#gpio-cells = <2>;
@@ -160,7 +160,7 @@
gpio5: gpio at 4805b000 {
compatible = "ti,omap4-gpio";
reg = <0x4805b000 0x200>;
- interrupts = <0 33 0x4>;
+ interrupts = <0 28 0x4>;
ti,hwmods = "gpio5";
gpio-controller;
#gpio-cells = <2>;
@@ -171,7 +171,7 @@
gpio6: gpio at 4805d000 {
compatible = "ti,omap4-gpio";
reg = <0x4805d000 0x200>;
- interrupts = <0 34 0x4>;
+ interrupts = <0 29 0x4>;
ti,hwmods = "gpio6";
gpio-controller;
#gpio-cells = <2>;
@@ -182,7 +182,7 @@
gpio7: gpio at 48051000 {
compatible = "ti,omap4-gpio";
reg = <0x48051000 0x200>;
- interrupts = <0 35 0x4>;
+ interrupts = <0 30 0x4>;
ti,hwmods = "gpio7";
gpio-controller;
#gpio-cells = <2>;
@@ -193,7 +193,7 @@
gpio8: gpio at 48053000 {
compatible = "ti,omap4-gpio";
reg = <0x48053000 0x200>;
- interrupts = <0 121 0x4>;
+ interrupts = <0 116 0x4>;
ti,hwmods = "gpio8";
gpio-controller;
#gpio-cells = <2>;
@@ -204,7 +204,7 @@
uart1: serial at 4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
- interrupts = <0 72 0x4>;
+ interrupts = <0 67 0x4>;
ti,hwmods = "uart1";
clock-frequency = <48000000>;
};
@@ -212,7 +212,7 @@
uart2: serial at 4806c000 {
compatible = "ti,omap4-uart";
reg = <0x4806c000 0x100>;
- interrupts = <0 73 0x4>;
+ interrupts = <0 68 0x4>;
ti,hwmods = "uart2";
clock-frequency = <48000000>;
};
@@ -220,7 +220,7 @@
uart3: serial at 48020000 {
compatible = "ti,omap4-uart";
reg = <0x48020000 0x100>;
- interrupts = <0 74 0x4>;
+ interrupts = <0 69 0x4>;
ti,hwmods = "uart3";
clock-frequency = <48000000>;
};
@@ -228,7 +228,7 @@
uart4: serial at 4806e000 {
compatible = "ti,omap4-uart";
reg = <0x4806e000 0x100>;
- interrupts = <0 70 0x4>;
+ interrupts = <0 65 0x4>;
ti,hwmods = "uart4";
clock-frequency = <48000000>;
};
@@ -236,7 +236,7 @@
uart5: serial at 48066000 {
compatible = "ti,omap4-uart";
reg = <0x48066000 0x100>;
- interrupts = <0 105 0x4>;
+ interrupts = <0 100 0x4>;
ti,hwmods = "uart5";
clock-frequency = <48000000>;
};
@@ -244,7 +244,7 @@
uart6: serial at 48068000 {
compatible = "ti,omap4-uart";
reg = <0x48068000 0x100>;
- interrupts = <0 106 0x4>;
+ interrupts = <0 101 0x4>;
ti,hwmods = "uart6";
clock-frequency = <48000000>;
};
@@ -252,7 +252,7 @@
timer1: timer at 4ae18000 {
compatible = "ti,omap5430-timer";
reg = <0x4ae18000 0x80>;
- interrupts = <0 37 0x4>;
+ interrupts = <0 32 0x4>;
ti,hwmods = "timer1";
ti,timer-alwon;
};
@@ -260,28 +260,28 @@
timer2: timer at 48032000 {
compatible = "ti,omap5430-timer";
reg = <0x48032000 0x80>;
- interrupts = <0 38 0x4>;
+ interrupts = <0 33 0x4>;
ti,hwmods = "timer2";
};
timer3: timer at 48034000 {
compatible = "ti,omap5430-timer";
reg = <0x48034000 0x80>;
- interrupts = <0 39 0x4>;
+ interrupts = <0 34 0x4>;
ti,hwmods = "timer3";
};
timer4: timer at 48036000 {
compatible = "ti,omap5430-timer";
reg = <0x48036000 0x80>;
- interrupts = <0 40 0x4>;
+ interrupts = <0 35 0x4>;
ti,hwmods = "timer4";
};
timer5: timer at 48820000 {
compatible = "ti,omap5430-timer";
reg = <0x48820000 0x80>;
- interrupts = <0 41 0x4>;
+ interrupts = <0 36 0x4>;
ti,hwmods = "timer5";
ti,timer-dsp;
};
@@ -289,7 +289,7 @@
timer6: timer at 48822000 {
compatible = "ti,omap5430-timer";
reg = <0x48822000 0x80>;
- interrupts = <0 42 0x4>;
+ interrupts = <0 37 0x4>;
ti,hwmods = "timer6";
ti,timer-dsp;
ti,timer-pwm;
@@ -298,7 +298,7 @@
timer7: timer at 48824000 {
compatible = "ti,omap5430-timer";
reg = <0x48824000 0x80>;
- interrupts = <0 43 0x4>;
+ interrupts = <0 38 0x4>;
ti,hwmods = "timer7";
ti,timer-dsp;
};
@@ -306,7 +306,7 @@
timer8: timer at 48826000 {
compatible = "ti,omap5430-timer";
reg = <0x48826000 0x80>;
- interrupts = <0 44 0x4>;
+ interrupts = <0 39 0x4>;
ti,hwmods = "timer8";
ti,timer-dsp;
ti,timer-pwm;
@@ -315,21 +315,21 @@
timer9: timer at 4803e000 {
compatible = "ti,omap5430-timer";
reg = <0x4803e000 0x80>;
- interrupts = <0 45 0x4>;
+ interrupts = <0 40 0x4>;
ti,hwmods = "timer9";
};
timer10: timer at 48086000 {
compatible = "ti,omap5430-timer";
reg = <0x48086000 0x80>;
- interrupts = <0 46 0x4>;
+ interrupts = <0 41 0x4>;
ti,hwmods = "timer10";
};
timer11: timer at 48088000 {
compatible = "ti,omap5430-timer";
reg = <0x48088000 0x80>;
- interrupts = <0 47 0x4>;
+ interrupts = <0 42 0x4>;
ti,hwmods = "timer11";
ti,timer-pwm;
};
@@ -337,21 +337,21 @@
wdt2: wdt at 4ae14000 {
compatible = "ti,omap4-wdt";
reg = <0x4ae14000 0x80>;
- interrupts = <0 80 0x4>;
+ interrupts = <0 75 0x4>;
ti,hwmods = "wd_timer2";
};
dmm: dmm at 4e000000 {
compatible = "ti,omap5-dmm";
reg = <0x4e000000 0x800>;
- interrupts = <0 113 0x4>;
+ interrupts = <0 108 0x4>;
ti,hwmods = "dmm";
};
i2c1: i2c at 48070000 {
compatible = "ti,omap4-i2c";
reg = <0x48070000 0x100>;
- interrupts = <0 56 0x4>;
+ interrupts = <0 51 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
@@ -360,7 +360,7 @@
i2c2: i2c at 48072000 {
compatible = "ti,omap4-i2c";
reg = <0x48072000 0x100>;
- interrupts = <0 57 0x4>;
+ interrupts = <0 52 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
@@ -369,7 +369,7 @@
i2c3: i2c at 48060000 {
compatible = "ti,omap4-i2c";
reg = <0x48060000 0x100>;
- interrupts = <0 61 0x4>;
+ interrupts = <0 56 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
@@ -378,7 +378,7 @@
i2c4: i2c at 4807a000 {
compatible = "ti,omap4-i2c";
reg = <0x4807a000 0x100>;
- interrupts = <0 62 0x4>;
+ interrupts = <0 57 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c4";
@@ -387,7 +387,7 @@
i2c5: i2c at 4807c000 {
compatible = "ti,omap4-i2c";
reg = <0x4807c000 0x100>;
- interrupts = <0 60 0x4>;
+ interrupts = <0 55 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c5";
@@ -396,7 +396,7 @@
mmc1: mmc at 4809c000 {
compatible = "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
- interrupts = <0 83 0x4>;
+ interrupts = <0 78 0x4>;
ti,hwmods = "mmc1";
ti,dual-volt;
ti,needs-special-reset;
@@ -407,7 +407,7 @@
mmc2: mmc at 480b4000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480b4000 0x400>;
- interrupts = <0 86 0x4>;
+ interrupts = <0 81 0x4>;
ti,hwmods = "mmc2";
ti,needs-special-reset;
dmas = <&sdma 47>, <&sdma 48>;
@@ -417,7 +417,7 @@
mmc3: mmc at 480ad000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480ad000 0x400>;
- interrupts = <0 94 0x4>;
+ interrupts = <0 89 0x4>;
ti,hwmods = "mmc3";
ti,needs-special-reset;
dmas = <&sdma 77>, <&sdma 78>;
@@ -427,7 +427,7 @@
mmc4: mmc at 480d1000 {
compatible = "ti,omap4-hsmmc";
reg = <0x480d1000 0x400>;
- interrupts = <0 96 0x4>;
+ interrupts = <0 91 0x4>;
ti,hwmods = "mmc4";
ti,needs-special-reset;
dmas = <&sdma 57>, <&sdma 58>;
@@ -437,7 +437,7 @@
mcspi1: spi at 48098000 {
compatible = "ti,omap4-mcspi";
reg = <0x48098000 0x200>;
- interrupts = <0 65 0x4>;
+ interrupts = <0 60 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi1";
@@ -457,7 +457,7 @@
mcspi2: spi at 4809a000 {
compatible = "ti,omap4-mcspi";
reg = <0x4809a000 0x200>;
- interrupts = <0 66 0x4>;
+ interrupts = <0 61 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi2";
@@ -472,7 +472,7 @@
mcspi3: spi at 480b8000 {
compatible = "ti,omap4-mcspi";
reg = <0x480b8000 0x200>;
- interrupts = <0 91 0x4>;
+ interrupts = <0 86 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi3";
@@ -484,7 +484,7 @@
mcspi4: spi at 480ba000 {
compatible = "ti,omap4-mcspi";
reg = <0x480ba000 0x200>;
- interrupts = <0 48 0x4>;
+ interrupts = <0 43 0x4>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "mcspi4";
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 5/6] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-09-30 13:59 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
The wakeup gen mask/unmask callback uses the irq element of the
irq_data to setup. The irq is the linux virtual irq number and
is same as the hardware irq number only when the parent irqchip
is setup as a legacy domain. When it is used as a linear domain,
the virtual irqs are allocated dynamically and wakeup gen code
cannot rely on these numbers to access the irq registers. Instead
use the hwirq element of the irq_data which represent the physical
irq number.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/mach-omap2/omap-wakeupgen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 4dc16c2c..244839c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -134,7 +134,7 @@ static void wakeupgen_mask(struct irq_data *d)
unsigned long flags;
raw_spin_lock_irqsave(&wakeupgen_lock, flags);
- _wakeupgen_clear(d->irq, irq_target_cpu[d->irq]);
+ _wakeupgen_clear(d->hwirq, irq_target_cpu[d->hwirq]);
raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
}
@@ -146,7 +146,7 @@ static void wakeupgen_unmask(struct irq_data *d)
unsigned long flags;
raw_spin_lock_irqsave(&wakeupgen_lock, flags);
- _wakeupgen_set(d->irq, irq_target_cpu[d->irq]);
+ _wakeupgen_set(d->hwirq, irq_target_cpu[d->hwirq]);
raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 5/6] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
The wakeup gen mask/unmask callback uses the irq element of the
irq_data to setup. The irq is the linux virtual irq number and
is same as the hardware irq number only when the parent irqchip
is setup as a legacy domain. When it is used as a linear domain,
the virtual irqs are allocated dynamically and wakeup gen code
cannot rely on these numbers to access the irq registers. Instead
use the hwirq element of the irq_data which represent the physical
irq number.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/mach-omap2/omap-wakeupgen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 4dc16c2c..244839c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -134,7 +134,7 @@ static void wakeupgen_mask(struct irq_data *d)
unsigned long flags;
raw_spin_lock_irqsave(&wakeupgen_lock, flags);
- _wakeupgen_clear(d->irq, irq_target_cpu[d->irq]);
+ _wakeupgen_clear(d->hwirq, irq_target_cpu[d->hwirq]);
raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
}
@@ -146,7 +146,7 @@ static void wakeupgen_unmask(struct irq_data *d)
unsigned long flags;
raw_spin_lock_irqsave(&wakeupgen_lock, flags);
- _wakeupgen_set(d->irq, irq_target_cpu[d->irq]);
+ _wakeupgen_set(d->hwirq, irq_target_cpu[d->hwirq]);
raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 5/6] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
The wakeup gen mask/unmask callback uses the irq element of the
irq_data to setup. The irq is the linux virtual irq number and
is same as the hardware irq number only when the parent irqchip
is setup as a legacy domain. When it is used as a linear domain,
the virtual irqs are allocated dynamically and wakeup gen code
cannot rely on these numbers to access the irq registers. Instead
use the hwirq element of the irq_data which represent the physical
irq number.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/mach-omap2/omap-wakeupgen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c
index 4dc16c2c..244839c 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -134,7 +134,7 @@ static void wakeupgen_mask(struct irq_data *d)
unsigned long flags;
raw_spin_lock_irqsave(&wakeupgen_lock, flags);
- _wakeupgen_clear(d->irq, irq_target_cpu[d->irq]);
+ _wakeupgen_clear(d->hwirq, irq_target_cpu[d->hwirq]);
raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
}
@@ -146,7 +146,7 @@ static void wakeupgen_unmask(struct irq_data *d)
unsigned long flags;
raw_spin_lock_irqsave(&wakeupgen_lock, flags);
- _wakeupgen_set(d->irq, irq_target_cpu[d->irq]);
+ _wakeupgen_set(d->hwirq, irq_target_cpu[d->hwirq]);
raw_spin_unlock_irqrestore(&wakeupgen_lock, flags);
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 6/6] ARM: DRA: Enable Crossbar IP support for DRA7XX
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-09-30 13:59 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/omap4-common.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8413252..10ec40c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,7 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_SMP
select COMMON_CLK
+ select IRQ_CROSSBAR
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index adbe86b..4692f1c 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -22,6 +22,7 @@
#include <linux/of_platform.h>
#include <linux/export.h>
#include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/irq-crossbar.h>
#include <linux/of_address.h>
#include <asm/hardware/cache-l2x0.h>
@@ -287,9 +288,12 @@ void __init omap_gic_of_init(void)
skip_errata_init:
omap_wakeupgen_init();
+ if (soc_is_dra7xx())
+ crossbar_init();
irqchip_init();
}
+
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 6/6] ARM: DRA: Enable Crossbar IP support for DRA7XX
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap
Cc: tglx, linus.walleij, santosh.shilimkar, linux, tony, rnayak,
marc.zyngier, r.sricharan, grant.likely, rob.herring,
mark.rutland
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/omap4-common.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8413252..10ec40c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,7 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_SMP
select COMMON_CLK
+ select IRQ_CROSSBAR
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index adbe86b..4692f1c 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -22,6 +22,7 @@
#include <linux/of_platform.h>
#include <linux/export.h>
#include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/irq-crossbar.h>
#include <linux/of_address.h>
#include <asm/hardware/cache-l2x0.h>
@@ -287,9 +288,12 @@ void __init omap_gic_of_init(void)
skip_errata_init:
omap_wakeupgen_init();
+ if (soc_is_dra7xx())
+ crossbar_init();
irqchip_init();
}
+
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* [RFC PATCH 6/6] ARM: DRA: Enable Crossbar IP support for DRA7XX
@ 2013-09-30 13:59 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sricharan R <r.sricharan@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/omap4-common.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8413252..10ec40c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -120,6 +120,7 @@ config SOC_DRA7XX
select ARM_GIC
select HAVE_SMP
select COMMON_CLK
+ select IRQ_CROSSBAR
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index adbe86b..4692f1c 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -22,6 +22,7 @@
#include <linux/of_platform.h>
#include <linux/export.h>
#include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/irq-crossbar.h>
#include <linux/of_address.h>
#include <asm/hardware/cache-l2x0.h>
@@ -287,9 +288,12 @@ void __init omap_gic_of_init(void)
skip_errata_init:
omap_wakeupgen_init();
+ if (soc_is_dra7xx())
+ crossbar_init();
irqchip_init();
}
+
#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
--
1.7.9.5
^ permalink raw reply related [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-09-30 14:16 ` Marc Zyngier
-1 siblings, 0 replies; 84+ messages in thread
From: Marc Zyngier @ 2013-09-30 14:16 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On 30/09/13 14:59, 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.
Isn't this just another chained interrupt controller? How is it GIC
specific?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 14:16 ` Marc Zyngier
0 siblings, 0 replies; 84+ messages in thread
From: Marc Zyngier @ 2013-09-30 14:16 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On 30/09/13 14:59, 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.
Isn't this just another chained interrupt controller? How is it GIC
specific?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 14:16 ` Marc Zyngier
0 siblings, 0 replies; 84+ messages in thread
From: Marc Zyngier @ 2013-09-30 14:16 UTC (permalink / raw)
To: linux-arm-kernel
On 30/09/13 14:59, 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.
Isn't this just another chained interrupt controller? How is it GIC
specific?
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 14:19 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-09-30 14:19 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, rob.herring, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 14:19 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-09-30 14:19 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-lFZ/pmaqli7XmaaqVzeoHQ, tony-4v6yS6AI5VpBDgjK7y7TUQ,
rnayak-l0cyMroinI0, marc.zyngier-5wv7dgnIgG8,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, mark.rutland-5wv7dgnIgG8
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 14:19 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-09-30 14:19 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 14:16 ` Marc Zyngier
(?)
@ 2013-09-30 14:22 ` Santosh Shilimkar
-1 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-09-30 14:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, linus.walleij, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
>
No it isn't a irq controller rather a event router. Patch is missing
reference to the previous discussion. Previous discussion is here [1]
Regards,
Santosh
[1] https://lkml.org/lkml/2013/9/13/413
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 14:22 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-09-30 14:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, linus.walleij, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
>
No it isn't a irq controller rather a event router. Patch is missing
reference to the previous discussion. Previous discussion is here [1]
Regards,
Santosh
[1] https://lkml.org/lkml/2013/9/13/413
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 14:22 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-09-30 14:22 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
>
No it isn't a irq controller rather a event router. Patch is missing
reference to the previous discussion. Previous discussion is here [1]
Regards,
Santosh
[1] https://lkml.org/lkml/2013/9/13/413
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 14:22 ` Santosh Shilimkar
(?)
@ 2013-09-30 14:28 ` Marc Zyngier
-1 siblings, 0 replies; 84+ messages in thread
From: Marc Zyngier @ 2013-09-30 14:28 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, linus.walleij, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On 30/09/13 15:22, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>>
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
Right. I need to go and understand that bit first.
Thanks Santosh.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 14:28 ` Marc Zyngier
0 siblings, 0 replies; 84+ messages in thread
From: Marc Zyngier @ 2013-09-30 14:28 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, linus.walleij, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On 30/09/13 15:22, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>>
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
Right. I need to go and understand that bit first.
Thanks Santosh.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 14:28 ` Marc Zyngier
0 siblings, 0 replies; 84+ messages in thread
From: Marc Zyngier @ 2013-09-30 14:28 UTC (permalink / raw)
To: linux-arm-kernel
On 30/09/13 15:22, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>>
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
Right. I need to go and understand that bit first.
Thanks Santosh.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 15:00 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 15:00 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Marc Zyngier, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, linus.walleij, linux, tony,
rnayak, grant.likely, rob.herring, Mark Rutland
On Monday 30 September 2013 07:52 PM, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
>
Sorry, missed adding that and thanks for pointing it.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 15:00 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 15:00 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Marc Zyngier, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA, tglx-hfZtesqFncYOwBW4kG4KsQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-lFZ/pmaqli7XmaaqVzeoHQ, tony-4v6yS6AI5VpBDgjK7y7TUQ,
rnayak-l0cyMroinI0, grant.likely-QSEj5FYQhm4dnm+yROfE0A,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ, Mark Rutland
On Monday 30 September 2013 07:52 PM, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
>
Sorry, missed adding that and thanks for pointing it.
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-09-30 15:00 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-09-30 15:00 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 30 September 2013 07:52 PM, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, 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.
>> Isn't this just another chained interrupt controller? How is it GIC
>> specific?
>>
> No it isn't a irq controller rather a event router. Patch is missing
> reference to the previous discussion. Previous discussion is here [1]
>
> Regards,
> Santosh
>
> [1] https://lkml.org/lkml/2013/9/13/413
>
Sorry, missed adding that and thanks for pointing it.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-09-30 13:59 ` Sricharan R
@ 2013-09-30 15:09 ` Rob Herring
-1 siblings, 0 replies; 84+ messages in thread
From: Rob Herring @ 2013-09-30 15:09 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, mark.rutland
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
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-09-30 15:09 ` Rob Herring
0 siblings, 0 replies; 84+ messages in thread
From: Rob Herring @ 2013-09-30 15:09 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-09-30 15:09 ` Rob Herring
(?)
@ 2013-10-01 11:13 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-01 11:13 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 11:13 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-01 11:13 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 11:13 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-01 11:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-10-01 11:13 ` Sricharan R
@ 2013-10-01 13:48 ` Rob Herring
-1 siblings, 0 replies; 84+ messages in thread
From: Rob Herring @ 2013-10-01 13:48 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 13:48 ` Rob Herring
0 siblings, 0 replies; 84+ messages in thread
From: Rob Herring @ 2013-10-01 13:48 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 13:57 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-10-01 13:57 UTC (permalink / raw)
To: Rob Herring, tglx
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 13:57 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-10-01 13:57 UTC (permalink / raw)
To: Rob Herring, tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: Sricharan R, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linux-lFZ/pmaqli7XmaaqVzeoHQ, tony-4v6yS6AI5VpBDgjK7y7TUQ,
rnayak-l0cyMroinI0, marc.zyngier-5wv7dgnIgG8,
grant.likely-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 13:57 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-10-01 13:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-10-01 13:57 ` Santosh Shilimkar
@ 2013-10-01 14:53 ` Rob Herring
-1 siblings, 0 replies; 84+ messages in thread
From: Rob Herring @ 2013-10-01 14:53 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: tglx, Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 14:53 ` Rob Herring
0 siblings, 0 replies; 84+ messages in thread
From: Rob Herring @ 2013-10-01 14:53 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-10-01 14:53 ` Rob Herring
(?)
@ 2013-10-01 15:07 ` Santosh Shilimkar
-1 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-10-01 15:07 UTC (permalink / raw)
To: Rob Herring
Cc: tglx, Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 15:07 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-10-01 15:07 UTC (permalink / raw)
To: Rob Herring
Cc: tglx, Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-01 15:07 ` Santosh Shilimkar
0 siblings, 0 replies; 84+ messages in thread
From: Santosh Shilimkar @ 2013-10-01 15:07 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 14:16 ` Marc Zyngier
(?)
@ 2013-10-08 11:23 ` Linus Walleij
-1 siblings, 0 replies; 84+ messages in thread
From: Linus Walleij @ 2013-10-08 11:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, santosh.shilimkar, linux,
tony, rnayak, grant.likely, rob.herring, Mark Rutland
On Mon, Sep 30, 2013 at 4:16 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
I thought so from the beginning but I was dead wrong, as pointed out
by tglx it is basically a hardware .map function, so its usecase will map
to the irqdomain .map/.unmap so to say.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-08 11:23 ` Linus Walleij
0 siblings, 0 replies; 84+ messages in thread
From: Linus Walleij @ 2013-10-08 11:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, tglx, santosh.shilimkar, linux,
tony, rnayak, grant.likely, rob.herring, Mark Rutland
On Mon, Sep 30, 2013 at 4:16 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
I thought so from the beginning but I was dead wrong, as pointed out
by tglx it is basically a hardware .map function, so its usecase will map
to the irqdomain .map/.unmap so to say.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-08 11:23 ` Linus Walleij
0 siblings, 0 replies; 84+ messages in thread
From: Linus Walleij @ 2013-10-08 11:23 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Sep 30, 2013 at 4:16 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 30/09/13 14:59, 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.
>
> Isn't this just another chained interrupt controller? How is it GIC
> specific?
I thought so from the beginning but I was dead wrong, as pointed out
by tglx it is basically a hardware .map function, so its usecase will map
to the irqdomain .map/.unmap so to say.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-10-01 15:07 ` Santosh Shilimkar
(?)
@ 2013-10-15 7:35 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-15 7:35 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, tglx, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-15 7:35 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-15 7:35 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Rob Herring, tglx, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, linux, tony, rnayak,
marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-15 7:35 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-15 7:35 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
2013-10-01 13:48 ` Rob Herring
@ 2013-10-24 8:57 ` Thomas Gleixner
-1 siblings, 0 replies; 84+ messages in thread
From: Thomas Gleixner @ 2013-10-24 8:57 UTC (permalink / raw)
To: Rob Herring
Cc: Sricharan R, linux-kernel, devicetree, linux-doc,
linux-arm-kernel, linux-omap, linus.walleij, santosh.shilimkar,
linux, tony, rnayak, marc.zyngier, grant.likely, mark.rutland
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP
@ 2013-10-24 8:57 ` Thomas Gleixner
0 siblings, 0 replies; 84+ messages in thread
From: Thomas Gleixner @ 2013-10-24 8:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 13:59 ` Sricharan R
@ 2013-10-24 9:12 ` Thomas Gleixner
-1 siblings, 0 replies; 84+ messages in thread
From: Thomas Gleixner @ 2013-10-24 9:12 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Mon, 30 Sep 2013, Sricharan R wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 1760ceb..c5778ab 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -72,6 +72,8 @@ struct gic_chip_data {
>
> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>
> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
> +
> /*
> * The GIC mapping of CPU interfaces does not necessarily match
> * the logical CPU numbering. Let's use a mapping as returned
> @@ -675,11 +677,26 @@ 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);
> +
> + if (gic_routable_irq_domain_ops &&
> + gic_routable_irq_domain_ops->map)
> + gic_routable_irq_domain_ops->map(d, irq, hw);
Shudder. Why are you sprinkling these if (ops && ops->fun)
conditionals all over the place instead of having a default ops
implementation which handles the non crossbar case by proper empty
functions. That code is not on a hot path so it does not matter at
all.
> }
> irq_set_chip_data(irq, d->host_data);
> return 0;
> }
>
> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
> +
> + if (hw > 32) {
Groan. This wants to be in the ops->unmap function. It's not related
to the GIC core code.
> + if (gic_routable_irq_domain_ops &&
> + gic_routable_irq_domain_ops->unmap)
> + 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,
> @@ -694,8 +711,15 @@ 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]) {
> + if (gic_routable_irq_domain_ops &&
> + gic_routable_irq_domain_ops->xlate)
> + *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
> + controller, intspec, intsize,
> + out_hwirq, out_type);
> + else
> + *out_hwirq += 16;
> + }
So if you have a default xlate ops implementation then this boils down to
if (!intspec[0])
*out_hwirq = routing_ops->xlate()
And the default (non crossbar) implementation would be:
return *out_hwirq + 16;
Thanks,
tglx
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 9:12 ` Thomas Gleixner
0 siblings, 0 replies; 84+ messages in thread
From: Thomas Gleixner @ 2013-10-24 9:12 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 30 Sep 2013, Sricharan R wrote:
> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> index 1760ceb..c5778ab 100644
> --- a/drivers/irqchip/irq-gic.c
> +++ b/drivers/irqchip/irq-gic.c
> @@ -72,6 +72,8 @@ struct gic_chip_data {
>
> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>
> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
> +
> /*
> * The GIC mapping of CPU interfaces does not necessarily match
> * the logical CPU numbering. Let's use a mapping as returned
> @@ -675,11 +677,26 @@ 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);
> +
> + if (gic_routable_irq_domain_ops &&
> + gic_routable_irq_domain_ops->map)
> + gic_routable_irq_domain_ops->map(d, irq, hw);
Shudder. Why are you sprinkling these if (ops && ops->fun)
conditionals all over the place instead of having a default ops
implementation which handles the non crossbar case by proper empty
functions. That code is not on a hot path so it does not matter at
all.
> }
> irq_set_chip_data(irq, d->host_data);
> return 0;
> }
>
> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
> +{
> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
> +
> + if (hw > 32) {
Groan. This wants to be in the ops->unmap function. It's not related
to the GIC core code.
> + if (gic_routable_irq_domain_ops &&
> + gic_routable_irq_domain_ops->unmap)
> + 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,
> @@ -694,8 +711,15 @@ 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]) {
> + if (gic_routable_irq_domain_ops &&
> + gic_routable_irq_domain_ops->xlate)
> + *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
> + controller, intspec, intsize,
> + out_hwirq, out_type);
> + else
> + *out_hwirq += 16;
> + }
So if you have a default xlate ops implementation then this boils down to
if (!intspec[0])
*out_hwirq = routing_ops->xlate()
And the default (non crossbar) implementation would be:
return *out_hwirq + 16;
Thanks,
tglx
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
2013-09-30 13:59 ` Sricharan R
@ 2013-10-24 9:20 ` Thomas Gleixner
-1 siblings, 0 replies; 84+ messages in thread
From: Thomas Gleixner @ 2013-10-24 9:20 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Mon, 30 Sep 2013, Sricharan R wrote:
> +/*
> + * @int_max: maximum number of supported interrupts
> + * @irq_map: array of interrupts to crossbar number mapping
> + * @crossbar_base: crossbar base address
> + * @register_offsets: offsets for each irq number
> + */
> +struct crossbar_device {
> + uint int_max;
> + uint *irq_map;
Why do you need another map here?
Isn't the linear_revmap of the irqdomain sufficient?
> +static inline const u32 allocate_free_irq(int cb_no)
> +{
> + int i;
> +
> + for (i = 0; i < cb->int_max; i++) {
> + if (cb->irq_map[i] == IRQ_FREE) {
> + cb->irq_map[i] = cb_no;
> + return i;
> + }
> + }
> +
> + return -ENODEV;
> +}
> +
> +static int crossbar_domain_xlate(struct irq_domain *d,
> + struct device_node *controller,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq,
> + unsigned int *out_type)
> +{
> + return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
Mooo. In the error case you return:
-ENODEV + GIC_IRQ_START == -19 + 32 == 13
Yikes.
> +
> + /*
> + * Register offsets are not linear because of the
> + * reserved irqs. so find and store the offsets once.
> + */
> + for (i = 0; i < max; i++) {
> + if (!cb->irq_map[i])
> + continue;
> +
> + cb->register_offsets[i] = reserved;
> + reserved += size;
I'm amazed by such a brilliant hardware design.
Thanks,
tglx
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 9:20 ` Thomas Gleixner
0 siblings, 0 replies; 84+ messages in thread
From: Thomas Gleixner @ 2013-10-24 9:20 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 30 Sep 2013, Sricharan R wrote:
> +/*
> + * @int_max: maximum number of supported interrupts
> + * @irq_map: array of interrupts to crossbar number mapping
> + * @crossbar_base: crossbar base address
> + * @register_offsets: offsets for each irq number
> + */
> +struct crossbar_device {
> + uint int_max;
> + uint *irq_map;
Why do you need another map here?
Isn't the linear_revmap of the irqdomain sufficient?
> +static inline const u32 allocate_free_irq(int cb_no)
> +{
> + int i;
> +
> + for (i = 0; i < cb->int_max; i++) {
> + if (cb->irq_map[i] == IRQ_FREE) {
> + cb->irq_map[i] = cb_no;
> + return i;
> + }
> + }
> +
> + return -ENODEV;
> +}
> +
> +static int crossbar_domain_xlate(struct irq_domain *d,
> + struct device_node *controller,
> + const u32 *intspec, unsigned int intsize,
> + unsigned long *out_hwirq,
> + unsigned int *out_type)
> +{
> + return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
Mooo. In the error case you return:
-ENODEV + GIC_IRQ_START == -19 + 32 == 13
Yikes.
> +
> + /*
> + * Register offsets are not linear because of the
> + * reserved irqs. so find and store the offsets once.
> + */
> + for (i = 0; i < max; i++) {
> + if (!cb->irq_map[i])
> + continue;
> +
> + cb->register_offsets[i] = reserved;
> + reserved += size;
I'm amazed by such a brilliant hardware design.
Thanks,
tglx
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-10-24 9:33 ` Kumar Gala
-1 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 9:33 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
> time, so they have to be muxed to the irq-controller appropriately.
> In such places a interrupt controllers are preceded by an CROSSBAR
> that provides flexibility in muxing the device requests to the controller
> inputs.
>
> This driver takes care a allocating a free irq and then configuring the
> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
> be called right before the irqchip_init, so that it is setup to handle the
> irqchip callbacks.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> ---
> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
> drivers/irqchip/Kconfig | 8 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
> include/linux/irqchip/irq-crossbar.h | 11 ++
> 5 files changed, 242 insertions(+)
> 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
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> new file mode 100644
> index 0000000..cdec2cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -0,0 +1,27 @@
> +Some socs have a large number of interrupts requests to service
> +the needs of its many peripherals and subsystems. All of the
> +interrupt lines from the subsystems are not needed at the same
> +time, so they have to be muxed to the irq-controller appropriately.
> +In such places a interrupt controllers are preceded by an CROSSBAR
> +that provides flexibility in muxing the device requests to the controller
> +inputs.
> +
> +Required properties:
> +- compatible : Should be "ti,irq-crossbar"
> +- reg: Base address and the size of the crossbar registers.
> +- max-irqs: Total number of irqs available at the interrupt controller.
Should be 'ti,max-irqs
> +- reg-size: Size of a individual register in bytes. Every individual
> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
Is this something that really needs to be encoded in the dts?
If we keep it should be ti,reg-size
> +- irqs-reserved: List of the reserved irq lines that are not muxed using
> + crossbar. These interrupt lines are reserved in the soc,
> + so crossbar bar driver should not consider them as free
> + lines.
> +
ti,irqs-reserved
> +Examples:
> + crossbar_mpu: @4a020000 {
Did you mean for there to be a label and no node name?
> + compatible = "ti,irq-crossbar";
> + reg = <0x4a002a48 0x130>;
> + max-irqs = <160>;
> + reg-size = <2>;
> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> + };
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 9:33 ` Kumar Gala
0 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 9:33 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
> time, so they have to be muxed to the irq-controller appropriately.
> In such places a interrupt controllers are preceded by an CROSSBAR
> that provides flexibility in muxing the device requests to the controller
> inputs.
>
> This driver takes care a allocating a free irq and then configuring the
> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
> be called right before the irqchip_init, so that it is setup to handle the
> irqchip callbacks.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> ---
> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
> drivers/irqchip/Kconfig | 8 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
> include/linux/irqchip/irq-crossbar.h | 11 ++
> 5 files changed, 242 insertions(+)
> 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
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> new file mode 100644
> index 0000000..cdec2cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -0,0 +1,27 @@
> +Some socs have a large number of interrupts requests to service
> +the needs of its many peripherals and subsystems. All of the
> +interrupt lines from the subsystems are not needed at the same
> +time, so they have to be muxed to the irq-controller appropriately.
> +In such places a interrupt controllers are preceded by an CROSSBAR
> +that provides flexibility in muxing the device requests to the controller
> +inputs.
> +
> +Required properties:
> +- compatible : Should be "ti,irq-crossbar"
> +- reg: Base address and the size of the crossbar registers.
> +- max-irqs: Total number of irqs available at the interrupt controller.
Should be 'ti,max-irqs
> +- reg-size: Size of a individual register in bytes. Every individual
> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
Is this something that really needs to be encoded in the dts?
If we keep it should be ti,reg-size
> +- irqs-reserved: List of the reserved irq lines that are not muxed using
> + crossbar. These interrupt lines are reserved in the soc,
> + so crossbar bar driver should not consider them as free
> + lines.
> +
ti,irqs-reserved
> +Examples:
> + crossbar_mpu: @4a020000 {
Did you mean for there to be a label and no node name?
> + compatible = "ti,irq-crossbar";
> + reg = <0x4a002a48 0x130>;
> + max-irqs = <160>;
> + reg-size = <2>;
> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> + };
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 9:33 ` Kumar Gala
0 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 9:33 UTC (permalink / raw)
To: linux-arm-kernel
On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
> time, so they have to be muxed to the irq-controller appropriately.
> In such places a interrupt controllers are preceded by an CROSSBAR
> that provides flexibility in muxing the device requests to the controller
> inputs.
>
> This driver takes care a allocating a free irq and then configuring the
> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
> be called right before the irqchip_init, so that it is setup to handle the
> irqchip callbacks.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> ---
> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
> drivers/irqchip/Kconfig | 8 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
> include/linux/irqchip/irq-crossbar.h | 11 ++
> 5 files changed, 242 insertions(+)
> 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
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> new file mode 100644
> index 0000000..cdec2cd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
> @@ -0,0 +1,27 @@
> +Some socs have a large number of interrupts requests to service
> +the needs of its many peripherals and subsystems. All of the
> +interrupt lines from the subsystems are not needed at the same
> +time, so they have to be muxed to the irq-controller appropriately.
> +In such places a interrupt controllers are preceded by an CROSSBAR
> +that provides flexibility in muxing the device requests to the controller
> +inputs.
> +
> +Required properties:
> +- compatible : Should be "ti,irq-crossbar"
> +- reg: Base address and the size of the crossbar registers.
> +- max-irqs: Total number of irqs available at the interrupt controller.
Should be 'ti,max-irqs
> +- reg-size: Size of a individual register in bytes. Every individual
> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
Is this something that really needs to be encoded in the dts?
If we keep it should be ti,reg-size
> +- irqs-reserved: List of the reserved irq lines that are not muxed using
> + crossbar. These interrupt lines are reserved in the soc,
> + so crossbar bar driver should not consider them as free
> + lines.
> +
ti,irqs-reserved
> +Examples:
> + crossbar_mpu: @4a020000 {
Did you mean for there to be a label and no node name?
> + compatible = "ti,irq-crossbar";
> + reg = <0x4a002a48 0x130>;
> + max-irqs = <160>;
> + reg-size = <2>;
> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
> + };
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-09-30 13:59 ` Sricharan R
(?)
@ 2013-10-24 9:38 ` Kumar Gala
-1 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 9:38 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Sep 30, 2013, at 8:59 AM, 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 <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 5 +++
> arch/arm/boot/dts/dra7.dtsi | 1 +
> drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
> include/linux/irqchip/arm-gic.h | 8 +++-
> 4 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 3dfb0c0..2d8c680 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.
>
> +- 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.
arm,routable-irqs
> Example:
>
> intc: interrupt-controller@fff11000 {
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 9:38 ` Kumar Gala
0 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 9:38 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Sep 30, 2013, at 8:59 AM, 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 <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 5 +++
> arch/arm/boot/dts/dra7.dtsi | 1 +
> drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
> include/linux/irqchip/arm-gic.h | 8 +++-
> 4 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 3dfb0c0..2d8c680 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.
>
> +- 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.
arm,routable-irqs
> Example:
>
> intc: interrupt-controller@fff11000 {
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 9:38 ` Kumar Gala
0 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 9:38 UTC (permalink / raw)
To: linux-arm-kernel
On Sep 30, 2013, at 8:59 AM, 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 <tglx@linutronix.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Rajendra Nayak <rnayak@ti.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Signed-off-by: Sricharan R <r.sricharan@ti.com>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 5 +++
> arch/arm/boot/dts/dra7.dtsi | 1 +
> drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
> include/linux/irqchip/arm-gic.h | 8 +++-
> 4 files changed, 61 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> index 3dfb0c0..2d8c680 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.
>
> +- 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.
arm,routable-irqs
> Example:
>
> intc: interrupt-controller at fff11000 {
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-10-24 9:12 ` Thomas Gleixner
(?)
@ 2013-10-24 10:21 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
Hi Thomas,
Thanks a lot for reviewing this.
On Thursday 24 October 2013 02:42 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 1760ceb..c5778ab 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -72,6 +72,8 @@ struct gic_chip_data {
>>
>> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
>> +
>> /*
>> * The GIC mapping of CPU interfaces does not necessarily match
>> * the logical CPU numbering. Let's use a mapping as returned
>> @@ -675,11 +677,26 @@ 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);
>> +
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->map)
>> + gic_routable_irq_domain_ops->map(d, irq, hw);
> Shudder. Why are you sprinkling these if (ops && ops->fun)
> conditionals all over the place instead of having a default ops
> implementation which handles the non crossbar case by proper empty
> functions. That code is not on a hot path so it does not matter at
> all.
>
Ok, Understand. Will add default ops to avoid these checks.
>> }
>> irq_set_chip_data(irq, d->host_data);
>> return 0;
>> }
>>
>> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
>> +{
>> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
>> +
>> + if (hw > 32) {
> Groan. This wants to be in the ops->unmap function. It's not related
> to the GIC core code.
Ok, will move this to unmap ops of the crossbar.
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->unmap)
>> + 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,
>> @@ -694,8 +711,15 @@ 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]) {
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->xlate)
>> + *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
>> + controller, intspec, intsize,
>> + out_hwirq, out_type);
>> + else
>> + *out_hwirq += 16;
>> + }
> So if you have a default xlate ops implementation then this boils down to
>
> if (!intspec[0])
> *out_hwirq = routing_ops->xlate()
>
> And the default (non crossbar) implementation would be:
>
> return *out_hwirq + 16;
>
Ok. This is better. Will change here.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 10:21 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
Hi Thomas,
Thanks a lot for reviewing this.
On Thursday 24 October 2013 02:42 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 1760ceb..c5778ab 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -72,6 +72,8 @@ struct gic_chip_data {
>>
>> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
>> +
>> /*
>> * The GIC mapping of CPU interfaces does not necessarily match
>> * the logical CPU numbering. Let's use a mapping as returned
>> @@ -675,11 +677,26 @@ 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);
>> +
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->map)
>> + gic_routable_irq_domain_ops->map(d, irq, hw);
> Shudder. Why are you sprinkling these if (ops && ops->fun)
> conditionals all over the place instead of having a default ops
> implementation which handles the non crossbar case by proper empty
> functions. That code is not on a hot path so it does not matter at
> all.
>
Ok, Understand. Will add default ops to avoid these checks.
>> }
>> irq_set_chip_data(irq, d->host_data);
>> return 0;
>> }
>>
>> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
>> +{
>> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
>> +
>> + if (hw > 32) {
> Groan. This wants to be in the ops->unmap function. It's not related
> to the GIC core code.
Ok, will move this to unmap ops of the crossbar.
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->unmap)
>> + 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,
>> @@ -694,8 +711,15 @@ 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]) {
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->xlate)
>> + *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
>> + controller, intspec, intsize,
>> + out_hwirq, out_type);
>> + else
>> + *out_hwirq += 16;
>> + }
> So if you have a default xlate ops implementation then this boils down to
>
> if (!intspec[0])
> *out_hwirq = routing_ops->xlate()
>
> And the default (non crossbar) implementation would be:
>
> return *out_hwirq + 16;
>
Ok. This is better. Will change here.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 10:21 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
Thanks a lot for reviewing this.
On Thursday 24 October 2013 02:42 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 1760ceb..c5778ab 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -72,6 +72,8 @@ struct gic_chip_data {
>>
>> static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> +const struct irq_domain_ops *gic_routable_irq_domain_ops;
>> +
>> /*
>> * The GIC mapping of CPU interfaces does not necessarily match
>> * the logical CPU numbering. Let's use a mapping as returned
>> @@ -675,11 +677,26 @@ 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);
>> +
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->map)
>> + gic_routable_irq_domain_ops->map(d, irq, hw);
> Shudder. Why are you sprinkling these if (ops && ops->fun)
> conditionals all over the place instead of having a default ops
> implementation which handles the non crossbar case by proper empty
> functions. That code is not on a hot path so it does not matter at
> all.
>
Ok, Understand. Will add default ops to avoid these checks.
>> }
>> irq_set_chip_data(irq, d->host_data);
>> return 0;
>> }
>>
>> +static void gic_irq_domain_unmap(struct irq_domain *d, unsigned int irq)
>> +{
>> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
>> +
>> + if (hw > 32) {
> Groan. This wants to be in the ops->unmap function. It's not related
> to the GIC core code.
Ok, will move this to unmap ops of the crossbar.
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->unmap)
>> + 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,
>> @@ -694,8 +711,15 @@ 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]) {
>> + if (gic_routable_irq_domain_ops &&
>> + gic_routable_irq_domain_ops->xlate)
>> + *out_hwirq = gic_routable_irq_domain_ops->xlate(d,
>> + controller, intspec, intsize,
>> + out_hwirq, out_type);
>> + else
>> + *out_hwirq += 16;
>> + }
> So if you have a default xlate ops implementation then this boils down to
>
> if (!intspec[0])
> *out_hwirq = routing_ops->xlate()
>
> And the default (non crossbar) implementation would be:
>
> return *out_hwirq + 16;
>
Ok. This is better. Will change here.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
2013-10-24 9:20 ` Thomas Gleixner
(?)
@ 2013-10-24 10:21 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
Hi Thomas,
On Thursday 24 October 2013 02:50 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> +/*
>> + * @int_max: maximum number of supported interrupts
>> + * @irq_map: array of interrupts to crossbar number mapping
>> + * @crossbar_base: crossbar base address
>> + * @register_offsets: offsets for each irq number
>> + */
>> +struct crossbar_device {
>> + uint int_max;
>> + uint *irq_map;
> Why do you need another map here?
>
> Isn't the linear_revmap of the irqdomain sufficient?
linear_revmap gives the linux-irq for hw-irq,
but here i need the crossbar number corresponding to
the hwirq allocated. This is needed for setting up the
crossbar register in map.
>> +static inline const u32 allocate_free_irq(int cb_no)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < cb->int_max; i++) {
>> + if (cb->irq_map[i] == IRQ_FREE) {
>> + cb->irq_map[i] = cb_no;
>> + return i;
>> + }
>> + }
>> +
>> + return -ENODEV;
>> +}
>> +
>> +static int crossbar_domain_xlate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq,
>> + unsigned int *out_type)
>> +{
>> + return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
> Mooo. In the error case you return:
>
> -ENODEV + GIC_IRQ_START == -19 + 32 == 13
>
> Yikes.
ya. will be a problem with error case. Will add a check here and
in the gic as well to check for the return value.
>> +
>> + /*
>> + * Register offsets are not linear because of the
>> + * reserved irqs. so find and store the offsets once.
>> + */
>> + for (i = 0; i < max; i++) {
>> + if (!cb->irq_map[i])
>> + continue;
>> +
>> + cb->register_offsets[i] = reserved;
>> + reserved += size;
> I'm amazed by such a brilliant hardware design.
>
> Thanks,
>
> tglx
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 10:21 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
Hi Thomas,
On Thursday 24 October 2013 02:50 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> +/*
>> + * @int_max: maximum number of supported interrupts
>> + * @irq_map: array of interrupts to crossbar number mapping
>> + * @crossbar_base: crossbar base address
>> + * @register_offsets: offsets for each irq number
>> + */
>> +struct crossbar_device {
>> + uint int_max;
>> + uint *irq_map;
> Why do you need another map here?
>
> Isn't the linear_revmap of the irqdomain sufficient?
linear_revmap gives the linux-irq for hw-irq,
but here i need the crossbar number corresponding to
the hwirq allocated. This is needed for setting up the
crossbar register in map.
>> +static inline const u32 allocate_free_irq(int cb_no)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < cb->int_max; i++) {
>> + if (cb->irq_map[i] == IRQ_FREE) {
>> + cb->irq_map[i] = cb_no;
>> + return i;
>> + }
>> + }
>> +
>> + return -ENODEV;
>> +}
>> +
>> +static int crossbar_domain_xlate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq,
>> + unsigned int *out_type)
>> +{
>> + return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
> Mooo. In the error case you return:
>
> -ENODEV + GIC_IRQ_START == -19 + 32 == 13
>
> Yikes.
ya. will be a problem with error case. Will add a check here and
in the gic as well to check for the return value.
>> +
>> + /*
>> + * Register offsets are not linear because of the
>> + * reserved irqs. so find and store the offsets once.
>> + */
>> + for (i = 0; i < max; i++) {
>> + if (!cb->irq_map[i])
>> + continue;
>> +
>> + cb->register_offsets[i] = reserved;
>> + reserved += size;
> I'm amazed by such a brilliant hardware design.
>
> Thanks,
>
> tglx
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 10:21 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Thomas,
On Thursday 24 October 2013 02:50 PM, Thomas Gleixner wrote:
> On Mon, 30 Sep 2013, Sricharan R wrote:
>> +/*
>> + * @int_max: maximum number of supported interrupts
>> + * @irq_map: array of interrupts to crossbar number mapping
>> + * @crossbar_base: crossbar base address
>> + * @register_offsets: offsets for each irq number
>> + */
>> +struct crossbar_device {
>> + uint int_max;
>> + uint *irq_map;
> Why do you need another map here?
>
> Isn't the linear_revmap of the irqdomain sufficient?
linear_revmap gives the linux-irq for hw-irq,
but here i need the crossbar number corresponding to
the hwirq allocated. This is needed for setting up the
crossbar register in map.
>> +static inline const u32 allocate_free_irq(int cb_no)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < cb->int_max; i++) {
>> + if (cb->irq_map[i] == IRQ_FREE) {
>> + cb->irq_map[i] = cb_no;
>> + return i;
>> + }
>> + }
>> +
>> + return -ENODEV;
>> +}
>> +
>> +static int crossbar_domain_xlate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq,
>> + unsigned int *out_type)
>> +{
>> + return allocate_free_irq(intspec[1]) + GIC_IRQ_START;
> Mooo. In the error case you return:
>
> -ENODEV + GIC_IRQ_START == -19 + 32 == 13
>
> Yikes.
ya. will be a problem with error case. Will add a check here and
in the gic as well to check for the return value.
>> +
>> + /*
>> + * Register offsets are not linear because of the
>> + * reserved irqs. so find and store the offsets once.
>> + */
>> + for (i = 0; i < max; i++) {
>> + if (!cb->irq_map[i])
>> + continue;
>> +
>> + cb->register_offsets[i] = reserved;
>> + reserved += size;
> I'm amazed by such a brilliant hardware design.
>
> Thanks,
>
> tglx
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
2013-10-24 9:33 ` Kumar Gala
(?)
@ 2013-10-24 10:43 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:43 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
Hi Kumar,
On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the irq-controller appropriately.
>> In such places a interrupt controllers are preceded by an CROSSBAR
>> that provides flexibility in muxing the device requests to the controller
>> inputs.
>>
>> This driver takes care a allocating a free irq and then configuring the
>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>> be called right before the irqchip_init, so that it is setup to handle the
>> irqchip callbacks.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>> drivers/irqchip/Kconfig | 8 +
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
>> include/linux/irqchip/irq-crossbar.h | 11 ++
>> 5 files changed, 242 insertions(+)
>> 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
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 0000000..cdec2cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,27 @@
>> +Some socs have a large number of interrupts requests to service
>> +the needs of its many peripherals and subsystems. All of the
>> +interrupt lines from the subsystems are not needed at the same
>> +time, so they have to be muxed to the irq-controller appropriately.
>> +In such places a interrupt controllers are preceded by an CROSSBAR
>> +that provides flexibility in muxing the device requests to the controller
>> +inputs.
>> +
>> +Required properties:
>> +- compatible : Should be "ti,irq-crossbar"
>> +- reg: Base address and the size of the crossbar registers.
>> +- max-irqs: Total number of irqs available at the interrupt controller.
> Should be 'ti,max-irqs
Ok, will correct.
>> +- reg-size: Size of a individual register in bytes. Every individual
>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
> Is this something that really needs to be encoded in the dts?
>
> If we keep it should be ti,reg-size
Currently, this is the only IP with a fixed register-size.
So this can be in the driver also. I thought keeping it
DT will avoid any hard-coding in driver.
>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>> + crossbar. These interrupt lines are reserved in the soc,
>> + so crossbar bar driver should not consider them as free
>> + lines.
>> +
> ti,irqs-reserved
Ok, will correct
>> +Examples:
>> + crossbar_mpu: @4a020000 {
> Did you mean for there to be a label and no node name?
>
ya, name is missing. Will add.
>> + compatible = "ti,irq-crossbar";
>> + reg = <0x4a002a48 0x130>;
>> + max-irqs = <160>;
>> + reg-size = <2>;
>> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>> + };
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 10:43 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:43 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
Hi Kumar,
On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the irq-controller appropriately.
>> In such places a interrupt controllers are preceded by an CROSSBAR
>> that provides flexibility in muxing the device requests to the controller
>> inputs.
>>
>> This driver takes care a allocating a free irq and then configuring the
>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>> be called right before the irqchip_init, so that it is setup to handle the
>> irqchip callbacks.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>> drivers/irqchip/Kconfig | 8 +
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
>> include/linux/irqchip/irq-crossbar.h | 11 ++
>> 5 files changed, 242 insertions(+)
>> 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
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 0000000..cdec2cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,27 @@
>> +Some socs have a large number of interrupts requests to service
>> +the needs of its many peripherals and subsystems. All of the
>> +interrupt lines from the subsystems are not needed at the same
>> +time, so they have to be muxed to the irq-controller appropriately.
>> +In such places a interrupt controllers are preceded by an CROSSBAR
>> +that provides flexibility in muxing the device requests to the controller
>> +inputs.
>> +
>> +Required properties:
>> +- compatible : Should be "ti,irq-crossbar"
>> +- reg: Base address and the size of the crossbar registers.
>> +- max-irqs: Total number of irqs available at the interrupt controller.
> Should be 'ti,max-irqs
Ok, will correct.
>> +- reg-size: Size of a individual register in bytes. Every individual
>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
> Is this something that really needs to be encoded in the dts?
>
> If we keep it should be ti,reg-size
Currently, this is the only IP with a fixed register-size.
So this can be in the driver also. I thought keeping it
DT will avoid any hard-coding in driver.
>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>> + crossbar. These interrupt lines are reserved in the soc,
>> + so crossbar bar driver should not consider them as free
>> + lines.
>> +
> ti,irqs-reserved
Ok, will correct
>> +Examples:
>> + crossbar_mpu: @4a020000 {
> Did you mean for there to be a label and no node name?
>
ya, name is missing. Will add.
>> + compatible = "ti,irq-crossbar";
>> + reg = <0x4a002a48 0x130>;
>> + max-irqs = <160>;
>> + reg-size = <2>;
>> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>> + };
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 10:43 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Kumar,
On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the irq-controller appropriately.
>> In such places a interrupt controllers are preceded by an CROSSBAR
>> that provides flexibility in muxing the device requests to the controller
>> inputs.
>>
>> This driver takes care a allocating a free irq and then configuring the
>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>> be called right before the irqchip_init, so that it is setup to handle the
>> irqchip callbacks.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>> drivers/irqchip/Kconfig | 8 +
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
>> include/linux/irqchip/irq-crossbar.h | 11 ++
>> 5 files changed, 242 insertions(+)
>> 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
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 0000000..cdec2cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,27 @@
>> +Some socs have a large number of interrupts requests to service
>> +the needs of its many peripherals and subsystems. All of the
>> +interrupt lines from the subsystems are not needed at the same
>> +time, so they have to be muxed to the irq-controller appropriately.
>> +In such places a interrupt controllers are preceded by an CROSSBAR
>> +that provides flexibility in muxing the device requests to the controller
>> +inputs.
>> +
>> +Required properties:
>> +- compatible : Should be "ti,irq-crossbar"
>> +- reg: Base address and the size of the crossbar registers.
>> +- max-irqs: Total number of irqs available at the interrupt controller.
> Should be 'ti,max-irqs
Ok, will correct.
>> +- reg-size: Size of a individual register in bytes. Every individual
>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
> Is this something that really needs to be encoded in the dts?
>
> If we keep it should be ti,reg-size
Currently, this is the only IP with a fixed register-size.
So this can be in the driver also. I thought keeping it
DT will avoid any hard-coding in driver.
>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>> + crossbar. These interrupt lines are reserved in the soc,
>> + so crossbar bar driver should not consider them as free
>> + lines.
>> +
> ti,irqs-reserved
Ok, will correct
>> +Examples:
>> + crossbar_mpu: @4a020000 {
> Did you mean for there to be a label and no node name?
>
ya, name is missing. Will add.
>> + compatible = "ti,irq-crossbar";
>> + reg = <0x4a002a48 0x130>;
>> + max-irqs = <160>;
>> + reg-size = <2>;
>> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>> + };
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
2013-10-24 9:38 ` Kumar Gala
(?)
@ 2013-10-24 10:44 ` Sricharan R
-1 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:44 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Thursday 24 October 2013 03:08 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8:59 AM, 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 <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 5 +++
>> arch/arm/boot/dts/dra7.dtsi | 1 +
>> drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
>> include/linux/irqchip/arm-gic.h | 8 +++-
>> 4 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> index 3dfb0c0..2d8c680 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.
>>
>> +- 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.
> arm,routable-irqs
ok will change here as well.
Thanks for reviewing.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 10:44 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:44 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Thursday 24 October 2013 03:08 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8:59 AM, 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 <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 5 +++
>> arch/arm/boot/dts/dra7.dtsi | 1 +
>> drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
>> include/linux/irqchip/arm-gic.h | 8 +++-
>> 4 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> index 3dfb0c0..2d8c680 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.
>>
>> +- 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.
> arm,routable-irqs
ok will change here as well.
Thanks for reviewing.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
@ 2013-10-24 10:44 ` Sricharan R
0 siblings, 0 replies; 84+ messages in thread
From: Sricharan R @ 2013-10-24 10:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 24 October 2013 03:08 PM, Kumar Gala wrote:
> On Sep 30, 2013, at 8:59 AM, 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 <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> ---
>> Documentation/devicetree/bindings/arm/gic.txt | 5 +++
>> arch/arm/boot/dts/dra7.dtsi | 1 +
>> drivers/irqchip/irq-gic.c | 57 +++++++++++++++++++++----
>> include/linux/irqchip/arm-gic.h | 8 +++-
>> 4 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> index 3dfb0c0..2d8c680 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.
>>
>> +- 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.
> arm,routable-irqs
ok will change here as well.
Thanks for reviewing.
Regards,
Sricharan
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
2013-10-24 10:43 ` Sricharan R
(?)
@ 2013-10-24 11:00 ` Kumar Gala
-1 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 11:00 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Oct 24, 2013, at 5:43 AM, Sricharan R wrote:
> Hi Kumar,
>
> On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
>> On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the irq-controller appropriately.
>>> In such places a interrupt controllers are preceded by an CROSSBAR
>>> that provides flexibility in muxing the device requests to the controller
>>> inputs.
>>>
>>> This driver takes care a allocating a free irq and then configuring the
>>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>>> be called right before the irqchip_init, so that it is setup to handle the
>>> irqchip callbacks.
>>>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Rajendra Nayak <rnayak@ti.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Grant Likely <grant.likely@linaro.org>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>>> ---
>>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>>> drivers/irqchip/Kconfig | 8 +
>>> drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
>>> include/linux/irqchip/irq-crossbar.h | 11 ++
>>> 5 files changed, 242 insertions(+)
>>> 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
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 0000000..cdec2cd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,27 @@
>>> +Some socs have a large number of interrupts requests to service
>>> +the needs of its many peripherals and subsystems. All of the
>>> +interrupt lines from the subsystems are not needed at the same
>>> +time, so they have to be muxed to the irq-controller appropriately.
>>> +In such places a interrupt controllers are preceded by an CROSSBAR
>>> +that provides flexibility in muxing the device requests to the controller
>>> +inputs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,irq-crossbar"
>>> +- reg: Base address and the size of the crossbar registers.
>>> +- max-irqs: Total number of irqs available at the interrupt controller.
>> Should be 'ti,max-irqs
> Ok, will correct.
>>> +- reg-size: Size of a individual register in bytes. Every individual
>>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
>> Is this something that really needs to be encoded in the dts?
>>
>> If we keep it should be ti,reg-size
> Currently, this is the only IP with a fixed register-size.
> So this can be in the driver also. I thought keeping it
> DT will avoid any hard-coding in driver.
I'd go with less in the DT at this point, if in the future you need this you can always add it later.
>>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>>> + crossbar. These interrupt lines are reserved in the soc,
>>> + so crossbar bar driver should not consider them as free
>>> + lines.
>>> +
>> ti,irqs-reserved
> Ok, will correct
>>> +Examples:
>>> + crossbar_mpu: @4a020000 {
>> Did you mean for there to be a label and no node name?
>>
> ya, name is missing. Will add.
>>> + compatible = "ti,irq-crossbar";
>>> + reg = <0x4a002a48 0x130>;
>>> + max-irqs = <160>;
>>> + reg-size = <2>;
>>> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>>> + };
>
> Regards,
> Sricharan
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 11:00 ` Kumar Gala
0 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 11:00 UTC (permalink / raw)
To: Sricharan R
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel,
linux-omap, tglx, linus.walleij, santosh.shilimkar, linux, tony,
rnayak, marc.zyngier, grant.likely, rob.herring, mark.rutland
On Oct 24, 2013, at 5:43 AM, Sricharan R wrote:
> Hi Kumar,
>
> On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
>> On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the irq-controller appropriately.
>>> In such places a interrupt controllers are preceded by an CROSSBAR
>>> that provides flexibility in muxing the device requests to the controller
>>> inputs.
>>>
>>> This driver takes care a allocating a free irq and then configuring the
>>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>>> be called right before the irqchip_init, so that it is setup to handle the
>>> irqchip callbacks.
>>>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Rajendra Nayak <rnayak@ti.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Grant Likely <grant.likely@linaro.org>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>>> ---
>>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>>> drivers/irqchip/Kconfig | 8 +
>>> drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
>>> include/linux/irqchip/irq-crossbar.h | 11 ++
>>> 5 files changed, 242 insertions(+)
>>> 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
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 0000000..cdec2cd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,27 @@
>>> +Some socs have a large number of interrupts requests to service
>>> +the needs of its many peripherals and subsystems. All of the
>>> +interrupt lines from the subsystems are not needed at the same
>>> +time, so they have to be muxed to the irq-controller appropriately.
>>> +In such places a interrupt controllers are preceded by an CROSSBAR
>>> +that provides flexibility in muxing the device requests to the controller
>>> +inputs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,irq-crossbar"
>>> +- reg: Base address and the size of the crossbar registers.
>>> +- max-irqs: Total number of irqs available at the interrupt controller.
>> Should be 'ti,max-irqs
> Ok, will correct.
>>> +- reg-size: Size of a individual register in bytes. Every individual
>>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
>> Is this something that really needs to be encoded in the dts?
>>
>> If we keep it should be ti,reg-size
> Currently, this is the only IP with a fixed register-size.
> So this can be in the driver also. I thought keeping it
> DT will avoid any hard-coding in driver.
I'd go with less in the DT at this point, if in the future you need this you can always add it later.
>>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>>> + crossbar. These interrupt lines are reserved in the soc,
>>> + so crossbar bar driver should not consider them as free
>>> + lines.
>>> +
>> ti,irqs-reserved
> Ok, will correct
>>> +Examples:
>>> + crossbar_mpu: @4a020000 {
>> Did you mean for there to be a label and no node name?
>>
> ya, name is missing. Will add.
>>> + compatible = "ti,irq-crossbar";
>>> + reg = <0x4a002a48 0x130>;
>>> + max-irqs = <160>;
>>> + reg-size = <2>;
>>> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>>> + };
>
> Regards,
> Sricharan
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
* [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
@ 2013-10-24 11:00 ` Kumar Gala
0 siblings, 0 replies; 84+ messages in thread
From: Kumar Gala @ 2013-10-24 11:00 UTC (permalink / raw)
To: linux-arm-kernel
On Oct 24, 2013, at 5:43 AM, Sricharan R wrote:
> Hi Kumar,
>
> On Thursday 24 October 2013 03:03 PM, Kumar Gala wrote:
>> On Sep 30, 2013, at 8: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 lines from the subsystems are not needed at the same
>>> time, so they have to be muxed to the irq-controller appropriately.
>>> In such places a interrupt controllers are preceded by an CROSSBAR
>>> that provides flexibility in muxing the device requests to the controller
>>> inputs.
>>>
>>> This driver takes care a allocating a free irq and then configuring the
>>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>>> be called right before the irqchip_init, so that it is setup to handle the
>>> irqchip callbacks.
>>>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Rajendra Nayak <rnayak@ti.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Grant Likely <grant.likely@linaro.org>
>>> Cc: Rob Herring <rob.herring@calxeda.com>
>>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>>> ---
>>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>>> drivers/irqchip/Kconfig | 8 +
>>> drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/irq-crossbar.c | 195 ++++++++++++++++++++
>>> include/linux/irqchip/irq-crossbar.h | 11 ++
>>> 5 files changed, 242 insertions(+)
>>> 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
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> new file mode 100644
>>> index 0000000..cdec2cd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>>> @@ -0,0 +1,27 @@
>>> +Some socs have a large number of interrupts requests to service
>>> +the needs of its many peripherals and subsystems. All of the
>>> +interrupt lines from the subsystems are not needed at the same
>>> +time, so they have to be muxed to the irq-controller appropriately.
>>> +In such places a interrupt controllers are preceded by an CROSSBAR
>>> +that provides flexibility in muxing the device requests to the controller
>>> +inputs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "ti,irq-crossbar"
>>> +- reg: Base address and the size of the crossbar registers.
>>> +- max-irqs: Total number of irqs available at the interrupt controller.
>> Should be 'ti,max-irqs
> Ok, will correct.
>>> +- reg-size: Size of a individual register in bytes. Every individual
>>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
>> Is this something that really needs to be encoded in the dts?
>>
>> If we keep it should be ti,reg-size
> Currently, this is the only IP with a fixed register-size.
> So this can be in the driver also. I thought keeping it
> DT will avoid any hard-coding in driver.
I'd go with less in the DT at this point, if in the future you need this you can always add it later.
>>> +- irqs-reserved: List of the reserved irq lines that are not muxed using
>>> + crossbar. These interrupt lines are reserved in the soc,
>>> + so crossbar bar driver should not consider them as free
>>> + lines.
>>> +
>> ti,irqs-reserved
> Ok, will correct
>>> +Examples:
>>> + crossbar_mpu: @4a020000 {
>> Did you mean for there to be a label and no node name?
>>
> ya, name is missing. Will add.
>>> + compatible = "ti,irq-crossbar";
>>> + reg = <0x4a002a48 0x130>;
>>> + max-irqs = <160>;
>>> + reg-size = <2>;
>>> + irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>>> + };
>
> Regards,
> Sricharan
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2013-10-24 13:30 UTC | newest]
Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-30 13:59 [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` [RFC PATCH 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 14:16 ` Marc Zyngier
2013-09-30 14:16 ` Marc Zyngier
2013-09-30 14:16 ` Marc Zyngier
2013-09-30 14:22 ` Santosh Shilimkar
2013-09-30 14:22 ` Santosh Shilimkar
2013-09-30 14:22 ` Santosh Shilimkar
2013-09-30 14:28 ` Marc Zyngier
2013-09-30 14:28 ` Marc Zyngier
2013-09-30 14:28 ` Marc Zyngier
2013-09-30 15:00 ` Sricharan R
2013-09-30 15:00 ` Sricharan R
2013-09-30 15:00 ` Sricharan R
2013-10-08 11:23 ` Linus Walleij
2013-10-08 11:23 ` Linus Walleij
2013-10-08 11:23 ` Linus Walleij
2013-10-24 9:12 ` Thomas Gleixner
2013-10-24 9:12 ` Thomas Gleixner
2013-10-24 10:21 ` Sricharan R
2013-10-24 10:21 ` Sricharan R
2013-10-24 10:21 ` Sricharan R
2013-10-24 9:38 ` Kumar Gala
2013-10-24 9:38 ` Kumar Gala
2013-10-24 9:38 ` Kumar Gala
2013-10-24 10:44 ` Sricharan R
2013-10-24 10:44 ` Sricharan R
2013-10-24 10:44 ` Sricharan R
2013-09-30 13:59 ` [RFC PATCH 2/6] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-10-24 9:20 ` Thomas Gleixner
2013-10-24 9:20 ` Thomas Gleixner
2013-10-24 10:21 ` Sricharan R
2013-10-24 10:21 ` Sricharan R
2013-10-24 10:21 ` Sricharan R
2013-10-24 9:33 ` Kumar Gala
2013-10-24 9:33 ` Kumar Gala
2013-10-24 9:33 ` Kumar Gala
2013-10-24 10:43 ` Sricharan R
2013-10-24 10:43 ` Sricharan R
2013-10-24 10:43 ` Sricharan R
2013-10-24 11:00 ` Kumar Gala
2013-10-24 11:00 ` Kumar Gala
2013-10-24 11:00 ` Kumar Gala
2013-09-30 13:59 ` [RFC PATCH 3/6] ARM: DTS: DRA: Add crossbar device binding Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` [RFC PATCH 4/6] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` [RFC PATCH 5/6] ARM: OMAP4+: Correct Wakeup-gen code to use physical irq number Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` [RFC PATCH 6/6] ARM: DRA: Enable Crossbar IP support for DRA7XX Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 13:59 ` Sricharan R
2013-09-30 14:19 ` [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP Santosh Shilimkar
2013-09-30 14:19 ` Santosh Shilimkar
2013-09-30 14:19 ` Santosh Shilimkar
2013-09-30 15:09 ` Rob Herring
2013-09-30 15:09 ` Rob Herring
2013-10-01 11:13 ` Sricharan R
2013-10-01 11:13 ` Sricharan R
2013-10-01 11:13 ` Sricharan R
2013-10-01 13:48 ` Rob Herring
2013-10-01 13:48 ` Rob Herring
2013-10-01 13:57 ` Santosh Shilimkar
2013-10-01 13:57 ` Santosh Shilimkar
2013-10-01 13:57 ` Santosh Shilimkar
2013-10-01 14:53 ` Rob Herring
2013-10-01 14:53 ` Rob Herring
2013-10-01 15:07 ` Santosh Shilimkar
2013-10-01 15:07 ` Santosh Shilimkar
2013-10-01 15:07 ` Santosh Shilimkar
2013-10-15 7:35 ` Sricharan R
2013-10-15 7:35 ` Sricharan R
2013-10-15 7:35 ` Sricharan R
2013-10-24 8:57 ` Thomas Gleixner
2013-10-24 8:57 ` Thomas Gleixner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.