[PATCH 00/12] MIPS: GIC device-tree support

[PATCH 00/12] MIPS: GIC device-tree support

[Andrew Bresticker]

This series add support for mapping and routing GIC interrupts through
the device-tree, which will be used on the upcoming interAptiv-based
Danube SoC.

- Patches 1 and 2 provide improvements to the CPU interrupt controller
  when used with DT.
- Patches 3 through 7 add device-tree support for the GIC.
- Patches 8 and 9 are misc. GIC irqchip cleanups.
- Patches 10 through 12 cleanup/fix GIC local interrupt support.

Based on 3.17-rc2 and boot tested on Danube (+ out of tree patches) and
Malta.  Build tested for SEAD-3.  Paul Burton has also tested this series
with his WIP Malta DT support [0].

[0] https://github.com/paulburton/linux/commits/wip-malta-dt

Andrew Bresticker (12):
  MIPS: Provide a generic plat_irq_dispatch
  MIPS: Set vint handler when mapping CPU interrupts
  of: Add binding document for MIPS GIC
  MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h
  MIPS: GIC: Add device-tree support
  MIPS: GIC: Add generic IPI support when using DT
  MIPS: GIC: Implement irq_set_type callback
  MIPS: GIC: Implement generic irq_ack/irq_eoi callbacks
  MIPS: GIC: Fix gic_set_affinity() return value
  MIPS: GIC: Support local interrupts
  MIPS: GIC: Use local interrupts for timer
  MIPS: Malta: Map GIC local interrupts

 Documentation/devicetree/bindings/mips/gic.txt |  50 +++
 arch/mips/include/asm/gic.h                    |  36 ++
 arch/mips/include/asm/mach-generic/irq.h       |   8 +
 arch/mips/include/asm/mach-sead3/irq.h         |   1 +
 arch/mips/include/asm/mips-boards/maltaint.h   |   2 -
 arch/mips/include/asm/mips-boards/sead3int.h   |   2 -
 arch/mips/kernel/cevt-gic.c                    |  16 +-
 arch/mips/kernel/irq-gic.c                     | 434 ++++++++++++++++++++++++-
 arch/mips/kernel/irq_cpu.c                     |  32 +-
 arch/mips/mti-malta/malta-int.c                |  44 ++-
 10 files changed, 585 insertions(+), 40 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/gic.txt

-- 
2.1.0.rc2.206.gedb03e5

[PATCH 01/12] MIPS: Provide a generic plat_irq_dispatch

[Andrew Bresticker]

For platforms which boot with device-tree and use the MIPS CPU interrupt
controller binding, a generic plat_irq_dispatch() can be used since all
CPU interrupts should be mapped through the CPU IRQ domain.  Implement a
plat_irq_dispatch() which simply handles the highest pending interrupt.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/kernel/irq_cpu.c | 28 +++++++++++++++++++++++-----
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c
index e498f2b..9cf8459 100644
--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -116,6 +116,24 @@ void __init mips_cpu_irq_init(void)
 }
 
 #ifdef CONFIG_IRQ_DOMAIN
+static struct irq_domain *mips_intc_domain;
+
+asmlinkage void __weak plat_irq_dispatch(void)
+{
+	unsigned int pending = read_c0_cause() & read_c0_status() & ST0_IM;
+	unsigned int hw;
+	int irq;
+
+	if (!pending) {
+		spurious_interrupt();
+		return;
+	}
+
+	hw = fls(pending) - CAUSEB_IP - 1;
+	irq = irq_linear_revmap(mips_intc_domain, hw);
+	do_IRQ(irq);
+}
+
 static int mips_cpu_intc_map(struct irq_domain *d, unsigned int irq,
 			     irq_hw_number_t hw)
 {
@@ -141,15 +159,15 @@ static const struct irq_domain_ops mips_cpu_intc_irq_domain_ops = {
 int __init mips_cpu_intc_init(struct device_node *of_node,
 			      struct device_node *parent)
 {
-	struct irq_domain *domain;
-
 	/* Mask interrupts. */
 	clear_c0_status(ST0_IM);
 	clear_c0_cause(CAUSEF_IP);
 
-	domain = irq_domain_add_legacy(of_node, 8, MIPS_CPU_IRQ_BASE, 0,
-				       &mips_cpu_intc_irq_domain_ops, NULL);
-	if (!domain)
+	mips_intc_domain = irq_domain_add_legacy(of_node, 8,
+						 MIPS_CPU_IRQ_BASE, 0,
+						 &mips_cpu_intc_irq_domain_ops,
+						 NULL);
+	if (!mips_intc_domain)
 		panic("Failed to add irqdomain for MIPS CPU");
 
 	return 0;
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 02/12] MIPS: Set vint handler when mapping CPU interrupts

[Andrew Bresticker]

When mapping an interrupt in the CPU IRQ domain, set the vint handler
for that interrupt if the CPU uses vectored interrupt handling.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/kernel/irq_cpu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/kernel/irq_cpu.c b/arch/mips/kernel/irq_cpu.c
index 9cf8459..33a4385 100644
--- a/arch/mips/kernel/irq_cpu.c
+++ b/arch/mips/kernel/irq_cpu.c
@@ -36,6 +36,7 @@
 #include <asm/irq_cpu.h>
 #include <asm/mipsregs.h>
 #include <asm/mipsmtregs.h>
+#include <asm/setup.h>
 
 static inline void unmask_mips_irq(struct irq_data *d)
 {
@@ -146,6 +147,9 @@ static int mips_cpu_intc_map(struct irq_domain *d, unsigned int irq,
 		chip = &mips_cpu_irq_controller;
 	}
 
+	if (cpu_has_vint)
+		set_vi_handler(hw, plat_irq_dispatch);
+
 	irq_set_chip_and_handler(irq, chip, handle_percpu_irq);
 
 	return 0;
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

The Global Interrupt Controller (GIC) present on certain MIPS systems
can be used to route external interrupts to individual VPEs and CPU
interrupt vectors.  It also supports a timer and software-generated
interrupts.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/gic.txt

diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
new file mode 100644
index 0000000..725f1ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/gic.txt
@@ -0,0 +1,50 @@
+MIPS Global Interrupt Controller (GIC)
+
+The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
+It also supports a timer and software-generated interrupts which can be
+used as IPIs.
+
+Required properties:
+- compatible : Should be "mti,global-interrupt-controller"
+- reg : Base address and length of the GIC registers.
+- interrupts : Core interrupts to which the GIC may route external interrupts.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt specifier.  Should be 3.
+  - The first cell is the GIC interrupt number.
+  - The second cell encodes the interrupt flags.
+    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
+    flags.
+  - The optional third cell indicates which CPU interrupt vector the GIC
+    interrupt should be routed to.  It is a 0-based index into the list of
+    GIC-to-CPU interrupts specified in the "interrupts" property described
+    above.  For example, a '2' in this cell will route the interrupt to the
+    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
+    be routed to the 1st core interrupt.
+
+Example:
+
+	cpu_intc: interrupt-controller@0 {
+		compatible = "mti,cpu-interrupt-controller";
+
+		interrupt-controller;
+		#interrupt-cells = <1>;
+	};
+
+	gic: interrupt-controller@1bdc0000 {
+		compatible = "mti,global-interrupt-controller";
+		reg = <0x1bdc0000 0x20000>;
+
+		interrupt-controller;
+		#interrupt-cells = <3>;
+
+		interrupt-parent = <&cpu_intc>;
+		interrupts = <3>, <4>;
+	};
+
+	uart@18101400 {
+		...
+		interrupt-parent = <&gic>;
+		interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
+		...
+	};
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

The Global Interrupt Controller (GIC) present on certain MIPS systems
can be used to route external interrupts to individual VPEs and CPU
interrupt vectors.  It also supports a timer and software-generated
interrupts.

Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/gic.txt

diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
new file mode 100644
index 0000000..725f1ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/gic.txt
@@ -0,0 +1,50 @@
+MIPS Global Interrupt Controller (GIC)
+
+The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
+It also supports a timer and software-generated interrupts which can be
+used as IPIs.
+
+Required properties:
+- compatible : Should be "mti,global-interrupt-controller"
+- reg : Base address and length of the GIC registers.
+- interrupts : Core interrupts to which the GIC may route external interrupts.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt specifier.  Should be 3.
+  - The first cell is the GIC interrupt number.
+  - The second cell encodes the interrupt flags.
+    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
+    flags.
+  - The optional third cell indicates which CPU interrupt vector the GIC
+    interrupt should be routed to.  It is a 0-based index into the list of
+    GIC-to-CPU interrupts specified in the "interrupts" property described
+    above.  For example, a '2' in this cell will route the interrupt to the
+    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
+    be routed to the 1st core interrupt.
+
+Example:
+
+	cpu_intc: interrupt-controller@0 {
+		compatible = "mti,cpu-interrupt-controller";
+
+		interrupt-controller;
+		#interrupt-cells = <1>;
+	};
+
+	gic: interrupt-controller@1bdc0000 {
+		compatible = "mti,global-interrupt-controller";
+		reg = <0x1bdc0000 0x20000>;
+
+		interrupt-controller;
+		#interrupt-cells = <3>;
+
+		interrupt-parent = <&cpu_intc>;
+		interrupts = <3>, <4>;
+	};
+
+	uart@18101400 {
+		...
+		interrupt-parent = <&gic>;
+		interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
+		...
+	};
-- 
2.1.0.rc2.206.gedb03e5

--
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

[PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Andrew Bresticker]

Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/include/asm/mach-generic/irq.h     | 6 ++++++
 arch/mips/include/asm/mach-sead3/irq.h       | 1 +
 arch/mips/include/asm/mips-boards/maltaint.h | 2 --
 arch/mips/include/asm/mips-boards/sead3int.h | 2 --
 4 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/mips/include/asm/mach-generic/irq.h b/arch/mips/include/asm/mach-generic/irq.h
index 139cd20..c0fc62b 100644
--- a/arch/mips/include/asm/mach-generic/irq.h
+++ b/arch/mips/include/asm/mach-generic/irq.h
@@ -36,4 +36,10 @@
 
 #endif /* CONFIG_IRQ_CPU */
 
+#ifdef CONFIG_IRQ_GIC
+#ifndef MIPS_GIC_IRQ_BASE
+#define MIPS_GIC_IRQ_BASE (MIPS_CPU_IRQ_BASE + 8)
+#endif
+#endif /* CONFIG_IRQ_GIC */
+
 #endif /* __ASM_MACH_GENERIC_IRQ_H */
diff --git a/arch/mips/include/asm/mach-sead3/irq.h b/arch/mips/include/asm/mach-sead3/irq.h
index d8106f7..52c75d5 100644
--- a/arch/mips/include/asm/mach-sead3/irq.h
+++ b/arch/mips/include/asm/mach-sead3/irq.h
@@ -1,6 +1,7 @@
 #ifndef __ASM_MACH_MIPS_IRQ_H
 #define __ASM_MACH_MIPS_IRQ_H
 
+#define MIPS_GIC_IRQ_BASE 0
 #define GIC_NUM_INTRS (24 + NR_CPUS * 2)
 #define NR_IRQS 256
 
diff --git a/arch/mips/include/asm/mips-boards/maltaint.h b/arch/mips/include/asm/mips-boards/maltaint.h
index e330732..9d23343 100644
--- a/arch/mips/include/asm/mips-boards/maltaint.h
+++ b/arch/mips/include/asm/mips-boards/maltaint.h
@@ -10,8 +10,6 @@
 #ifndef _MIPS_MALTAINT_H
 #define _MIPS_MALTAINT_H
 
-#define MIPS_GIC_IRQ_BASE	(MIPS_CPU_IRQ_BASE + 8)
-
 /*
  * Interrupts 0..15 are used for Malta ISA compatible interrupts
  */
diff --git a/arch/mips/include/asm/mips-boards/sead3int.h b/arch/mips/include/asm/mips-boards/sead3int.h
index 6b17aaf..11ebec9 100644
--- a/arch/mips/include/asm/mips-boards/sead3int.h
+++ b/arch/mips/include/asm/mips-boards/sead3int.h
@@ -14,6 +14,4 @@
 #define GIC_BASE_ADDR		0x1b1c0000
 #define GIC_ADDRSPACE_SZ	(128 * 1024)
 
-#define MIPS_GIC_IRQ_BASE	(MIPS_CPU_IRQ_BASE + 0)
-
 #endif /* !(_MIPS_SEAD3INT_H) */
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 05/12] MIPS: GIC: Add device-tree support

[Andrew Bresticker]

Add device-tree support for the MIPS GIC.  With DT, no per-platform
static device interrupt mapping is supplied and instead all device
interrupts are specified through the DT.  The GIC-to-CPU interrupts
must also be specified in the DT.

Platforms using DT-based probing of the GIC need only supply the
GIC_NUM_INTRS and, if necessary, MIPS_GIC_IRQ_BASE values and
call of_irq_init() with an of_device_id table including the GIC.

Currenlty only legacy and vecotred interrupt modes are supported.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/include/asm/gic.h |  15 ++++++
 arch/mips/kernel/irq-gic.c  | 122 +++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index d7699cf..1146803 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -339,6 +339,10 @@ struct gic_shared_intr_map {
 #define GIC_CPU_INT3		3 /* .		      */
 #define GIC_CPU_INT4		4 /* .		      */
 #define GIC_CPU_INT5		5 /* Core Interrupt 7 */
+#define GIC_NUM_CPU_INT		6
+
+/* Add 2 to convert GIC CPU pin to core interrupt */
+#define GIC_CPU_PIN_OFFSET	2
 
 /* Local GIC interrupts. */
 #define GIC_INT_TMR		(GIC_CPU_INT5)
@@ -381,4 +385,15 @@ extern void gic_disable_interrupt(int irq_vec);
 extern void gic_irq_ack(struct irq_data *d);
 extern void gic_finish_irq(struct irq_data *d);
 extern void gic_platform_init(int irqs, struct irq_chip *irq_controller);
+
+#ifdef CONFIG_IRQ_DOMAIN
+extern int gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline int gic_of_init(struct device_node *node,
+			      struct device_node *parent)
+{
+	return 0;
+}
+#endif
+
 #endif /* _ASM_GICREGS_H */
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 9e9d8b9..be8bea4 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -8,8 +8,10 @@
  */
 #include <linux/bitmap.h>
 #include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/smp.h>
-#include <linux/irq.h>
+#include <linux/interrupt.h>
 #include <linux/clocksource.h>
 
 #include <asm/io.h>
@@ -243,7 +245,7 @@ static DEFINE_SPINLOCK(gic_lock);
 static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
 			    bool force)
 {
-	unsigned int irq = (d->irq - gic_irq_base);
+	unsigned int irq = d->irq - gic_irq_base;
 	cpumask_t	tmp = CPU_MASK_NONE;
 	unsigned long	flags;
 	int		i;
@@ -400,3 +402,119 @@ void __init gic_init(unsigned long gic_base_addr,
 
 	gic_platform_init(numintrs, &gic_irq_controller);
 }
+
+#ifdef CONFIG_IRQ_DOMAIN
+/* CPU core IRQs used by GIC */
+static int gic_cpu_pin[GIC_NUM_CPU_INT];
+static int num_gic_cpu_pins;
+
+/* Index of core IRQ used by a particular GIC IRQ */
+static int gic_irq_pin[GIC_NUM_INTRS];
+
+static inline int gic_irq_to_cpu_pin(unsigned int hwirq)
+{
+	return gic_cpu_pin[gic_irq_pin[hwirq]] - MIPS_CPU_IRQ_BASE -
+		GIC_CPU_PIN_OFFSET;
+}
+
+static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
+			      irq_hw_number_t hw)
+{
+	irq_set_chip_and_handler(irq, &gic_irq_controller, handle_level_irq);
+
+	GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hw)),
+		 GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hw));
+	/* Map to VPE 0 by default */
+	GIC_SH_MAP_TO_VPE_SMASK(hw, 0);
+	set_bit(hw, pcpu_masks[0].pcpu_mask);
+
+	return 0;
+}
+
+static int gic_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+	if (intsize != 2 && intsize != 3)
+		return -EINVAL;
+
+	if (intspec[0] >= GIC_NUM_INTRS)
+		return -EINVAL;
+	*out_hwirq = intspec[0];
+
+	*out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+
+	if (intsize == 3) {
+		if (intspec[2] >= num_gic_cpu_pins)
+			return -EINVAL;
+		gic_irq_pin[intspec[0]] = intspec[2];
+	}
+
+	return 0;
+}
+
+static const struct irq_domain_ops gic_irq_domain_ops = {
+	.map = gic_irq_domain_map,
+	.xlate = gic_irq_domain_xlate,
+};
+
+static void gic_irq_dispatch(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_domain *domain = irq_get_handler_data(irq);
+	unsigned int hwirq;
+
+	while ((hwirq = gic_get_int()) != GIC_NUM_INTRS) {
+		irq = irq_linear_revmap(domain, hwirq);
+		generic_handle_irq(irq);
+	}
+}
+
+void __init __weak gic_platform_init(int irqs, struct irq_chip *irq_controller)
+{
+}
+
+int __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+	struct irq_domain *domain;
+	struct resource res;
+	int i;
+
+	if (cpu_has_veic) {
+		pr_err("GIC EIC mode not supported with DT yet\n");
+		return -ENODEV;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(gic_cpu_pin); i++) {
+		gic_cpu_pin[i] = irq_of_parse_and_map(node, i);
+		if (!gic_cpu_pin[i])
+			break;
+		num_gic_cpu_pins++;
+	}
+	if (!num_gic_cpu_pins) {
+		pr_err("No GIC to CPU interrupts specified\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(node, 0, &res)) {
+		pr_err("Failed to get GIC memory range\n");
+		return -ENODEV;
+	}
+
+	gic_init(res.start, resource_size(&res), NULL, 0, MIPS_GIC_IRQ_BASE);
+
+	domain = irq_domain_add_legacy(node, GIC_NUM_INTRS, MIPS_GIC_IRQ_BASE,
+				       0, &gic_irq_domain_ops, NULL);
+	if (!domain) {
+		pr_err("Failed to add GIC IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < num_gic_cpu_pins; i++) {
+		irq_set_chained_handler(gic_cpu_pin[i], gic_irq_dispatch);
+		irq_set_handler_data(gic_cpu_pin[i], domain);
+	}
+
+	return 0;
+}
+#endif
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 05/12] MIPS: GIC: Add device-tree support

[Andrew Bresticker]

Add device-tree support for the MIPS GIC.  With DT, no per-platform
static device interrupt mapping is supplied and instead all device
interrupts are specified through the DT.  The GIC-to-CPU interrupts
must also be specified in the DT.

Platforms using DT-based probing of the GIC need only supply the
GIC_NUM_INTRS and, if necessary, MIPS_GIC_IRQ_BASE values and
call of_irq_init() with an of_device_id table including the GIC.

Currenlty only legacy and vecotred interrupt modes are supported.

Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 arch/mips/include/asm/gic.h |  15 ++++++
 arch/mips/kernel/irq-gic.c  | 122 +++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index d7699cf..1146803 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -339,6 +339,10 @@ struct gic_shared_intr_map {
 #define GIC_CPU_INT3		3 /* .		      */
 #define GIC_CPU_INT4		4 /* .		      */
 #define GIC_CPU_INT5		5 /* Core Interrupt 7 */
+#define GIC_NUM_CPU_INT		6
+
+/* Add 2 to convert GIC CPU pin to core interrupt */
+#define GIC_CPU_PIN_OFFSET	2
 
 /* Local GIC interrupts. */
 #define GIC_INT_TMR		(GIC_CPU_INT5)
@@ -381,4 +385,15 @@ extern void gic_disable_interrupt(int irq_vec);
 extern void gic_irq_ack(struct irq_data *d);
 extern void gic_finish_irq(struct irq_data *d);
 extern void gic_platform_init(int irqs, struct irq_chip *irq_controller);
+
+#ifdef CONFIG_IRQ_DOMAIN
+extern int gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline int gic_of_init(struct device_node *node,
+			      struct device_node *parent)
+{
+	return 0;
+}
+#endif
+
 #endif /* _ASM_GICREGS_H */
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 9e9d8b9..be8bea4 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -8,8 +8,10 @@
  */
 #include <linux/bitmap.h>
 #include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
 #include <linux/smp.h>
-#include <linux/irq.h>
+#include <linux/interrupt.h>
 #include <linux/clocksource.h>
 
 #include <asm/io.h>
@@ -243,7 +245,7 @@ static DEFINE_SPINLOCK(gic_lock);
 static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
 			    bool force)
 {
-	unsigned int irq = (d->irq - gic_irq_base);
+	unsigned int irq = d->irq - gic_irq_base;
 	cpumask_t	tmp = CPU_MASK_NONE;
 	unsigned long	flags;
 	int		i;
@@ -400,3 +402,119 @@ void __init gic_init(unsigned long gic_base_addr,
 
 	gic_platform_init(numintrs, &gic_irq_controller);
 }
+
+#ifdef CONFIG_IRQ_DOMAIN
+/* CPU core IRQs used by GIC */
+static int gic_cpu_pin[GIC_NUM_CPU_INT];
+static int num_gic_cpu_pins;
+
+/* Index of core IRQ used by a particular GIC IRQ */
+static int gic_irq_pin[GIC_NUM_INTRS];
+
+static inline int gic_irq_to_cpu_pin(unsigned int hwirq)
+{
+	return gic_cpu_pin[gic_irq_pin[hwirq]] - MIPS_CPU_IRQ_BASE -
+		GIC_CPU_PIN_OFFSET;
+}
+
+static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
+			      irq_hw_number_t hw)
+{
+	irq_set_chip_and_handler(irq, &gic_irq_controller, handle_level_irq);
+
+	GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hw)),
+		 GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hw));
+	/* Map to VPE 0 by default */
+	GIC_SH_MAP_TO_VPE_SMASK(hw, 0);
+	set_bit(hw, pcpu_masks[0].pcpu_mask);
+
+	return 0;
+}
+
+static int gic_irq_domain_xlate(struct irq_domain *d, struct device_node *ctrlr,
+				const u32 *intspec, unsigned int intsize,
+				unsigned long *out_hwirq,
+				unsigned int *out_type)
+{
+	if (intsize != 2 && intsize != 3)
+		return -EINVAL;
+
+	if (intspec[0] >= GIC_NUM_INTRS)
+		return -EINVAL;
+	*out_hwirq = intspec[0];
+
+	*out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
+
+	if (intsize == 3) {
+		if (intspec[2] >= num_gic_cpu_pins)
+			return -EINVAL;
+		gic_irq_pin[intspec[0]] = intspec[2];
+	}
+
+	return 0;
+}
+
+static const struct irq_domain_ops gic_irq_domain_ops = {
+	.map = gic_irq_domain_map,
+	.xlate = gic_irq_domain_xlate,
+};
+
+static void gic_irq_dispatch(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_domain *domain = irq_get_handler_data(irq);
+	unsigned int hwirq;
+
+	while ((hwirq = gic_get_int()) != GIC_NUM_INTRS) {
+		irq = irq_linear_revmap(domain, hwirq);
+		generic_handle_irq(irq);
+	}
+}
+
+void __init __weak gic_platform_init(int irqs, struct irq_chip *irq_controller)
+{
+}
+
+int __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+	struct irq_domain *domain;
+	struct resource res;
+	int i;
+
+	if (cpu_has_veic) {
+		pr_err("GIC EIC mode not supported with DT yet\n");
+		return -ENODEV;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(gic_cpu_pin); i++) {
+		gic_cpu_pin[i] = irq_of_parse_and_map(node, i);
+		if (!gic_cpu_pin[i])
+			break;
+		num_gic_cpu_pins++;
+	}
+	if (!num_gic_cpu_pins) {
+		pr_err("No GIC to CPU interrupts specified\n");
+		return -ENODEV;
+	}
+
+	if (of_address_to_resource(node, 0, &res)) {
+		pr_err("Failed to get GIC memory range\n");
+		return -ENODEV;
+	}
+
+	gic_init(res.start, resource_size(&res), NULL, 0, MIPS_GIC_IRQ_BASE);
+
+	domain = irq_domain_add_legacy(node, GIC_NUM_INTRS, MIPS_GIC_IRQ_BASE,
+				       0, &gic_irq_domain_ops, NULL);
+	if (!domain) {
+		pr_err("Failed to add GIC IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < num_gic_cpu_pins; i++) {
+		irq_set_chained_handler(gic_cpu_pin[i], gic_irq_dispatch);
+		irq_set_handler_data(gic_cpu_pin[i], domain);
+	}
+
+	return 0;
+}
+#endif
-- 
2.1.0.rc2.206.gedb03e5

--
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

[PATCH 06/12] MIPS: GIC: Add generic IPI support when using DT

[Andrew Bresticker]

When DT-based probing is used for the GIC and the GIC is also used
for IPIs (i.e. MIPS_GIC_IPI=y), set up the last 2 * NR_CPUs GIC
interrupts as the reschedule and call IPIs.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/kernel/irq-gic.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 86 insertions(+)

diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index be8bea4..42558eb 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -10,6 +10,7 @@
 #include <linux/init.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/sched.h>
 #include <linux/smp.h>
 #include <linux/interrupt.h>
 #include <linux/clocksource.h>
@@ -417,6 +418,89 @@ static inline int gic_irq_to_cpu_pin(unsigned int hwirq)
 		GIC_CPU_PIN_OFFSET;
 }
 
+#ifdef CONFIG_MIPS_GIC_IPI
+static int gic_resched_int_base;
+static int gic_call_int_base;
+
+unsigned int plat_ipi_resched_int_xlate(unsigned int cpu)
+{
+	return gic_resched_int_base + cpu;
+}
+
+unsigned int plat_ipi_call_int_xlate(unsigned int cpu)
+{
+	return gic_call_int_base + cpu;
+}
+
+static irqreturn_t ipi_resched_interrupt(int irq, void *dev_id)
+{
+	scheduler_ipi();
+
+	return IRQ_HANDLED;
+}
+
+static irqreturn_t ipi_call_interrupt(int irq, void *dev_id)
+{
+	smp_call_function_interrupt();
+
+	return IRQ_HANDLED;
+}
+
+static struct irqaction irq_resched = {
+	.handler	= ipi_resched_interrupt,
+	.flags		= IRQF_PERCPU,
+	.name		= "IPI resched"
+};
+
+static struct irqaction irq_call = {
+	.handler	= ipi_call_interrupt,
+	.flags		= IRQF_PERCPU,
+	.name		= "IPI call"
+};
+
+static __init void gic_ipi_init_one(struct irq_domain *domain,
+				    unsigned int hwirq, int cpu,
+				    struct irqaction *action)
+{
+	int irq = irq_create_mapping(domain, hwirq);
+	int i;
+
+	GIC_SET_POLARITY(hwirq, GIC_POL_POS);
+	GIC_SET_TRIGGER(hwirq, GIC_TRIG_EDGE);
+	GIC_SH_MAP_TO_VPE_SMASK(hwirq, cpu);
+	GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hwirq)),
+		 GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hwirq));
+	GIC_CLR_INTR_MASK(hwirq);
+	gic_irq_flags[hwirq] |= GIC_TRIG_EDGE;
+
+	for (i = 0; i < ARRAY_SIZE(pcpu_masks); i++)
+		clear_bit(hwirq, pcpu_masks[i].pcpu_mask);
+	set_bit(hwirq, pcpu_masks[cpu].pcpu_mask);
+
+	irq_set_chip_and_handler(irq, &gic_irq_controller, handle_percpu_irq);
+	setup_irq(irq, action);
+}
+
+static __init void gic_ipi_init(struct irq_domain *domain)
+{
+	int i;
+
+	/* Use last 2 * NR_CPUS interrupts as IPIs */
+	gic_resched_int_base = GIC_NUM_INTRS - nr_cpu_ids;
+	gic_call_int_base = gic_resched_int_base - nr_cpu_ids;
+
+	for (i = 0; i < nr_cpu_ids; i++) {
+		gic_ipi_init_one(domain, gic_call_int_base + i, i, &irq_call);
+		gic_ipi_init_one(domain, gic_resched_int_base + i, i,
+				 &irq_resched);
+	}
+}
+#else
+static inline void gic_ipi_init(struct irq_domain *domain)
+{
+}
+#endif
+
 static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 			      irq_hw_number_t hw)
 {
@@ -515,6 +599,8 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
 		irq_set_handler_data(gic_cpu_pin[i], domain);
 	}
 
+	gic_ipi_init(domain);
+
 	return 0;
 }
 #endif
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 07/12] MIPS: GIC: Implement irq_set_type callback

[Andrew Bresticker]

Implement an irq_set_type callback for the GIC which is used to set
the polarity and trigger type of GIC interrupts.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/include/asm/gic.h |  9 ++++++++
 arch/mips/kernel/irq-gic.c  | 53 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 62 insertions(+)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index 1146803..3853c15 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -23,6 +23,8 @@
 #define GIC_POL_NEG			0
 #define GIC_TRIG_EDGE			1
 #define GIC_TRIG_LEVEL			0
+#define GIC_TRIG_DUAL_ENABLE		1
+#define GIC_TRIG_DUAL_DISABLE		0
 
 #define MSK(n) ((1 << (n)) - 1)
 #define REG32(addr)		(*(volatile unsigned int *) (addr))
@@ -179,6 +181,13 @@
 		GIC_INTR_OFS(intr)), (1 << GIC_INTR_BIT(intr)), \
 		(trig) << GIC_INTR_BIT(intr))
 
+/* Dual edge triggering : Reset Value is always 0 */
+#define GIC_SH_SET_DUAL_OFS		0x0200
+#define GIC_SET_DUAL(intr, dual) \
+	GICBIS(GIC_REG_ADDR(SHARED, GIC_SH_SET_DUAL_OFS + \
+		GIC_INTR_OFS(intr)), (1 << GIC_INTR_BIT(intr)), \
+		(dual) << GIC_INTR_BIT(intr))
+
 /* Mask manipulation */
 #define GIC_SH_SMASK_OFS		0x0380
 #define GIC_SET_INTR_MASK(intr) \
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 42558eb..01fcc28 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -47,6 +47,8 @@ static struct gic_pcpu_mask pcpu_masks[NR_CPUS];
 static struct gic_pending_regs pending_regs[NR_CPUS];
 static struct gic_intrmask_regs intrmask_regs[NR_CPUS];
 
+static struct irq_chip gic_irq_controller;
+
 #if defined(CONFIG_CSRC_GIC) || defined(CONFIG_CEVT_GIC)
 cycle_t gic_read_count(void)
 {
@@ -240,6 +242,56 @@ static void gic_unmask_irq(struct irq_data *d)
 	GIC_SET_INTR_MASK(d->irq - gic_irq_base);
 }
 
+static int gic_set_type(struct irq_data *d, unsigned int type)
+{
+	unsigned int irq = d->irq - gic_irq_base;
+	bool is_edge;
+
+	switch (type & IRQ_TYPE_SENSE_MASK) {
+	case IRQ_TYPE_EDGE_FALLING:
+		GIC_SET_POLARITY(irq, GIC_POL_POS);
+		GIC_SET_TRIGGER(irq, GIC_TRIG_EDGE);
+		GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+		is_edge = true;
+		break;
+	case IRQ_TYPE_EDGE_RISING:
+		GIC_SET_POLARITY(irq, GIC_POL_NEG);
+		GIC_SET_TRIGGER(irq, GIC_TRIG_EDGE);
+		GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+		is_edge = true;
+		break;
+	case IRQ_TYPE_EDGE_BOTH:
+		/* polarity is irrelevant in this case */
+		GIC_SET_TRIGGER(irq, GIC_TRIG_EDGE);
+		GIC_SET_DUAL(irq, GIC_TRIG_DUAL_ENABLE);
+		is_edge = true;
+		break;
+	case IRQ_TYPE_LEVEL_LOW:
+		GIC_SET_POLARITY(irq, GIC_POL_NEG);
+		GIC_SET_TRIGGER(irq, GIC_TRIG_LEVEL);
+		GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+		is_edge = false;
+		break;
+	case IRQ_TYPE_LEVEL_HIGH:
+	default:
+		GIC_SET_POLARITY(irq, GIC_POL_POS);
+		GIC_SET_TRIGGER(irq, GIC_TRIG_LEVEL);
+		GIC_SET_DUAL(irq, GIC_TRIG_DUAL_DISABLE);
+		is_edge = false;
+		break;
+	}
+
+	if (is_edge) {
+		gic_irq_flags[irq] |= GIC_TRIG_EDGE;
+		__irq_set_handler_locked(d->irq, handle_edge_irq);
+	} else {
+		gic_irq_flags[irq] &= ~GIC_TRIG_EDGE;
+		__irq_set_handler_locked(d->irq, handle_level_irq);
+	}
+
+	return 0;
+}
+
 #ifdef CONFIG_SMP
 static DEFINE_SPINLOCK(gic_lock);
 
@@ -280,6 +332,7 @@ static struct irq_chip gic_irq_controller = {
 	.irq_mask_ack		=	gic_mask_irq,
 	.irq_unmask		=	gic_unmask_irq,
 	.irq_eoi		=	gic_finish_irq,
+	.irq_set_type		=	gic_set_type,
 #ifdef CONFIG_SMP
 	.irq_set_affinity	=	gic_set_affinity,
 #endif
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 08/12] MIPS: GIC: Implement generic irq_ack/irq_eoi callbacks

[Andrew Bresticker]

Implement a default gic_irq_ack() and gic_finish_irq().  These are
suitable for handling IPIs on Malta and the upcoming Danube board.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/kernel/irq-gic.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 01fcc28..1764b01 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -242,6 +242,20 @@ static void gic_unmask_irq(struct irq_data *d)
 	GIC_SET_INTR_MASK(d->irq - gic_irq_base);
 }
 
+void __weak gic_irq_ack(struct irq_data *d)
+{
+	GIC_CLR_INTR_MASK(d->irq - gic_irq_base);
+
+	/* Clear edge detector */
+	if (gic_irq_flags[d->irq - gic_irq_base] & GIC_TRIG_EDGE)
+		GICWRITE(GIC_REG(SHARED, GIC_SH_WEDGE), d->irq - gic_irq_base);
+}
+
+void __weak gic_finish_irq(struct irq_data *d)
+{
+	GIC_SET_INTR_MASK(d->irq - gic_irq_base);
+}
+
 static int gic_set_type(struct irq_data *d, unsigned int type)
 {
 	unsigned int irq = d->irq - gic_irq_base;
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 09/12] MIPS: GIC: Fix gic_set_affinity() return value

[Andrew Bresticker]

If the online CPU check in gic_set_affinity() fails, return a proper
errno value instead of -1.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/kernel/irq-gic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 1764b01..4ee3ad8 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -319,7 +319,7 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
 
 	cpumask_and(&tmp, cpumask, cpu_online_mask);
 	if (cpus_empty(tmp))
-		return -1;
+		return -EINVAL;
 
 	/* Assumption : cpumask refers to a single CPU */
 	spin_lock_irqsave(&gic_lock, flags);
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 10/12] MIPS: GIC: Support local interrupts

[Andrew Bresticker]

The MIPS GIC supports 7 local interrupts, 5 of which are just core
interrupts which can be re-routed through the GIC.  This patch adds
support for mapping and handling the remaining two: the GIC timer
and watchdog.  GIC interrupts from 0 to GIC_NUM_INTRS are still the
shared external interrupts while interrupts from GIC_NUM_INTRS to
GIC_NUM_INTRS + GIC_NUM_LOCAL_INTRS are local interrupts.

With device-tree based probing, the GIC local interrupts will be routed
to the first GIC-to-CPU pin.  For platforms using a static mapping, the
local interrupts can be initialized by extending the interrupt mapping
table passed to gic_init.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/include/asm/gic.h              |  12 ++
 arch/mips/include/asm/mach-generic/irq.h |   2 +
 arch/mips/kernel/irq-gic.c               | 183 +++++++++++++++++++++++++++----
 3 files changed, 175 insertions(+), 22 deletions(-)

diff --git a/arch/mips/include/asm/gic.h b/arch/mips/include/asm/gic.h
index 3853c15..d5b2d84 100644
--- a/arch/mips/include/asm/gic.h
+++ b/arch/mips/include/asm/gic.h
@@ -217,6 +217,10 @@
 #define GIC_VPE_COMPARE_LO_OFS		0x00a0
 #define GIC_VPE_COMPARE_HI_OFS		0x00a4
 
+#define GIC_VPE_MAP_OFS			0x0040
+#define GIC_VPE_MAP_TO_PIN(intr) \
+	(GIC_VPE_MAP_OFS + 4 * (intr))
+
 #define GIC_VPE_EIC_SHADOW_SET_BASE	0x0100
 #define GIC_VPE_EIC_SS(intr) \
 	(GIC_VPE_EIC_SHADOW_SET_BASE + (4 * intr))
@@ -354,6 +358,11 @@ struct gic_shared_intr_map {
 #define GIC_CPU_PIN_OFFSET	2
 
 /* Local GIC interrupts. */
+#define GIC_LOCAL_INTR_WD	0 /* GIC watchdog timer */
+#define GIC_LOCAL_INTR_COMPARE	1 /* GIC count/compare timer */
+#define GIC_NUM_LOCAL_INTRS	2
+
+/* Pin mapping for CPU interrupts routable through the GIC. */
 #define GIC_INT_TMR		(GIC_CPU_INT5)
 #define GIC_INT_PERFCTR		(GIC_CPU_INT5)
 
@@ -389,6 +398,9 @@ extern void gic_bind_eic_interrupt(int irq, int set);
 extern unsigned int gic_get_timer_pending(void);
 extern void gic_get_int_mask(unsigned long *dst, const unsigned long *src);
 extern unsigned int gic_get_int(void);
+extern void gic_get_local_int_mask(unsigned long *dst,
+				   const unsigned long *src);
+extern unsigned int gic_get_local_int(void);
 extern void gic_enable_interrupt(int irq_vec);
 extern void gic_disable_interrupt(int irq_vec);
 extern void gic_irq_ack(struct irq_data *d);
diff --git a/arch/mips/include/asm/mach-generic/irq.h b/arch/mips/include/asm/mach-generic/irq.h
index c0fc62b..89bc185 100644
--- a/arch/mips/include/asm/mach-generic/irq.h
+++ b/arch/mips/include/asm/mach-generic/irq.h
@@ -40,6 +40,8 @@
 #ifndef MIPS_GIC_IRQ_BASE
 #define MIPS_GIC_IRQ_BASE (MIPS_CPU_IRQ_BASE + 8)
 #endif
+
+#define MIPS_GIC_LOCAL_IRQ_BASE (MIPS_GIC_IRQ_BASE + GIC_NUM_INTRS)
 #endif /* CONFIG_IRQ_GIC */
 
 #endif /* __ASM_MACH_GENERIC_IRQ_H */
diff --git a/arch/mips/kernel/irq-gic.c b/arch/mips/kernel/irq-gic.c
index 4ee3ad8..7f66d6e 100644
--- a/arch/mips/kernel/irq-gic.c
+++ b/arch/mips/kernel/irq-gic.c
@@ -49,6 +49,21 @@ static struct gic_intrmask_regs intrmask_regs[NR_CPUS];
 
 static struct irq_chip gic_irq_controller;
 
+static inline bool gic_is_local_irq(unsigned int hwirq)
+{
+	return hwirq >= GIC_NUM_INTRS;
+}
+
+static inline unsigned int gic_hw_to_local_irq(unsigned int hwirq)
+{
+	return hwirq - GIC_NUM_INTRS;
+}
+
+static inline unsigned int gic_local_to_hw_irq(unsigned int irq)
+{
+	return irq + GIC_NUM_INTRS;
+}
+
 #if defined(CONFIG_CSRC_GIC) || defined(CONFIG_CEVT_GIC)
 cycle_t gic_read_count(void)
 {
@@ -232,28 +247,77 @@ unsigned int gic_get_int(void)
 	return find_first_bit(interrupts, GIC_NUM_INTRS);
 }
 
+void gic_get_local_int_mask(unsigned long *dst, const unsigned long *src)
+{
+	unsigned long pending, intrmask;
+
+	GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_PEND), pending);
+	GICREAD(GIC_REG(VPE_LOCAL, GIC_VPE_MASK), intrmask);
+
+	bitmap_and(&pending, &pending, &intrmask, GIC_NUM_LOCAL_INTRS);
+	bitmap_and(dst, src, &pending, GIC_NUM_LOCAL_INTRS);
+}
+
+unsigned int gic_get_local_int(void)
+{
+	unsigned long interrupts;
+
+	bitmap_fill(&interrupts, GIC_NUM_LOCAL_INTRS);
+	gic_get_local_int_mask(&interrupts, &interrupts);
+
+	return find_first_bit(&interrupts, GIC_NUM_LOCAL_INTRS);
+}
+
 static void gic_mask_irq(struct irq_data *d)
 {
-	GIC_CLR_INTR_MASK(d->irq - gic_irq_base);
+	unsigned int irq = d->irq - gic_irq_base;
+
+	if (gic_is_local_irq(irq)) {
+		GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_RMASK),
+			 1 << GIC_INTR_BIT(gic_hw_to_local_irq(irq)));
+	} else {
+		GIC_CLR_INTR_MASK(irq);
+	}
 }
 
 static void gic_unmask_irq(struct irq_data *d)
 {
-	GIC_SET_INTR_MASK(d->irq - gic_irq_base);
+	unsigned int irq = d->irq - gic_irq_base;
+
+	if (gic_is_local_irq(irq)) {
+		GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_SMASK),
+			 1 << GIC_INTR_BIT(gic_hw_to_local_irq(irq)));
+	} else {
+		GIC_SET_INTR_MASK(irq);
+	}
 }
 
 void __weak gic_irq_ack(struct irq_data *d)
 {
-	GIC_CLR_INTR_MASK(d->irq - gic_irq_base);
+	unsigned int irq = d->irq - gic_irq_base;
 
-	/* Clear edge detector */
-	if (gic_irq_flags[d->irq - gic_irq_base] & GIC_TRIG_EDGE)
-		GICWRITE(GIC_REG(SHARED, GIC_SH_WEDGE), d->irq - gic_irq_base);
+	if (gic_is_local_irq(irq)) {
+		GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_RMASK),
+			 1 << GIC_INTR_BIT(gic_hw_to_local_irq(irq)));
+	} else {
+		GIC_CLR_INTR_MASK(irq);
+
+		/* Clear edge detector */
+		if (gic_irq_flags[irq] & GIC_TRIG_EDGE)
+			GICWRITE(GIC_REG(SHARED, GIC_SH_WEDGE), irq);
+	}
 }
 
 void __weak gic_finish_irq(struct irq_data *d)
 {
-	GIC_SET_INTR_MASK(d->irq - gic_irq_base);
+	unsigned int irq = d->irq - gic_irq_base;
+
+	if (gic_is_local_irq(irq)) {
+		GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_SMASK),
+			 1 << GIC_INTR_BIT(gic_hw_to_local_irq(irq)));
+	} else {
+		GIC_SET_INTR_MASK(irq);
+	}
 }
 
 static int gic_set_type(struct irq_data *d, unsigned int type)
@@ -261,6 +325,9 @@ static int gic_set_type(struct irq_data *d, unsigned int type)
 	unsigned int irq = d->irq - gic_irq_base;
 	bool is_edge;
 
+	if (gic_is_local_irq(irq))
+		return -EINVAL;
+
 	switch (type & IRQ_TYPE_SENSE_MASK) {
 	case IRQ_TYPE_EDGE_FALLING:
 		GIC_SET_POLARITY(irq, GIC_POL_POS);
@@ -317,6 +384,9 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *cpumask,
 	unsigned long	flags;
 	int		i;
 
+	if (gic_is_local_irq(irq))
+		return -EINVAL;
+
 	cpumask_and(&tmp, cpumask, cpu_online_mask);
 	if (cpus_empty(tmp))
 		return -EINVAL;
@@ -402,6 +472,42 @@ static void __init gic_setup_intr(unsigned int intr, unsigned int cpu,
 		gic_irq_flags[intr] |= GIC_TRIG_EDGE;
 }
 
+static void __init gic_setup_local_intr(unsigned int intr, unsigned int pin,
+				unsigned int flags)
+{
+	struct gic_shared_intr_map *map_ptr;
+	unsigned int local_irq = gic_hw_to_local_irq(intr);
+	int i;
+
+	/* Setup Intr to Pin mapping */
+	for (i = 0; i < nr_cpu_ids; i++) {
+		GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_OTHER_ADDR), i);
+		if (pin & GIC_MAP_TO_NMI_MSK) {
+			GICWRITE(GIC_REG_ADDR(VPE_OTHER,
+					GIC_VPE_MAP_TO_PIN(local_irq)), pin);
+		} else {
+			GICWRITE(GIC_REG_ADDR(VPE_OTHER,
+					GIC_VPE_MAP_TO_PIN(local_irq)),
+				 GIC_MAP_TO_PIN_MSK | pin);
+		}
+	}
+
+	if (!(pin & GIC_MAP_TO_NMI_MSK) && cpu_has_veic) {
+		set_vi_handler(pin + GIC_PIN_TO_VEC_OFFSET,
+			       gic_eic_irq_dispatch);
+		map_ptr = &gic_shared_intr_map[pin + GIC_PIN_TO_VEC_OFFSET];
+		if (map_ptr->num_shared_intr >= GIC_MAX_SHARED_INTR)
+			BUG();
+		map_ptr->intr_list[map_ptr->num_shared_intr++] = intr;
+	}
+
+	/* Init Intr Masks */
+	GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_RMASK),
+		 1 << GIC_INTR_BIT(local_irq));
+
+	irq_set_percpu_devid(gic_irq_base + intr);
+}
+
 static void __init gic_basic_init(int numintrs, int numvpes,
 			struct gic_intr_map *intrmap, int mapsize)
 {
@@ -434,12 +540,17 @@ static void __init gic_basic_init(int numintrs, int numvpes,
 		cpu = intrmap[i].cpunum;
 		if (cpu == GIC_UNUSED)
 			continue;
-		gic_setup_intr(i,
-			intrmap[i].cpunum,
-			intrmap[i].pin + pin_offset,
-			intrmap[i].polarity,
-			intrmap[i].trigtype,
-			intrmap[i].flags);
+		if (gic_is_local_irq(i))
+			gic_setup_local_intr(i,
+				intrmap[i].pin + pin_offset,
+				intrmap[i].flags);
+		else
+			gic_setup_intr(i,
+				intrmap[i].cpunum,
+				intrmap[i].pin + pin_offset,
+				intrmap[i].polarity,
+				intrmap[i].trigtype,
+				intrmap[i].flags);
 	}
 
 	vpe_local_setup(numvpes);
@@ -468,7 +579,8 @@ void __init gic_init(unsigned long gic_base_addr,
 
 	gic_basic_init(numintrs, numvpes, intr_map, intr_map_size);
 
-	gic_platform_init(numintrs, &gic_irq_controller);
+	gic_platform_init(GIC_NUM_INTRS + GIC_NUM_LOCAL_INTRS,
+			  &gic_irq_controller);
 }
 
 #ifdef CONFIG_IRQ_DOMAIN
@@ -481,6 +593,8 @@ static int gic_irq_pin[GIC_NUM_INTRS];
 
 static inline int gic_irq_to_cpu_pin(unsigned int hwirq)
 {
+	if (gic_is_local_irq(hwirq))
+		return gic_cpu_pin[0] - MIPS_CPU_IRQ_BASE - GIC_CPU_PIN_OFFSET;
 	return gic_cpu_pin[gic_irq_pin[hwirq]] - MIPS_CPU_IRQ_BASE -
 		GIC_CPU_PIN_OFFSET;
 }
@@ -571,13 +685,31 @@ static inline void gic_ipi_init(struct irq_domain *domain)
 static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
 			      irq_hw_number_t hw)
 {
-	irq_set_chip_and_handler(irq, &gic_irq_controller, handle_level_irq);
+	int i;
 
-	GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hw)),
-		 GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hw));
-	/* Map to VPE 0 by default */
-	GIC_SH_MAP_TO_VPE_SMASK(hw, 0);
-	set_bit(hw, pcpu_masks[0].pcpu_mask);
+	if (gic_is_local_irq(hw)) {
+		int local_irq = gic_hw_to_local_irq(hw);
+
+		irq_set_chip_and_handler(irq, &gic_irq_controller,
+					 handle_percpu_irq);
+		irq_set_percpu_devid(irq);
+
+		for (i = 0; i < nr_cpu_ids; i++) {
+			GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_OTHER_ADDR), i);
+			GICWRITE(GIC_REG_ADDR(VPE_OTHER,
+					      GIC_VPE_MAP_TO_PIN(local_irq)),
+				 GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hw));
+		}
+	} else {
+		irq_set_chip_and_handler(irq, &gic_irq_controller,
+					 handle_level_irq);
+
+		GICWRITE(GIC_REG_ADDR(SHARED, GIC_SH_MAP_TO_PIN(hw)),
+			 GIC_MAP_TO_PIN_MSK | gic_irq_to_cpu_pin(hw));
+		/* Map to VPE 0 by default */
+		GIC_SH_MAP_TO_VPE_SMASK(hw, 0);
+		set_bit(hw, pcpu_masks[0].pcpu_mask);
+	}
 
 	return 0;
 }
@@ -615,6 +747,11 @@ static void gic_irq_dispatch(unsigned int irq, struct irq_desc *desc)
 	struct irq_domain *domain = irq_get_handler_data(irq);
 	unsigned int hwirq;
 
+	while ((hwirq = gic_get_local_int()) != GIC_NUM_LOCAL_INTRS) {
+		irq = irq_linear_revmap(domain, gic_local_to_hw_irq(hwirq));
+		generic_handle_irq(irq);
+	}
+
 	while ((hwirq = gic_get_int()) != GIC_NUM_INTRS) {
 		irq = irq_linear_revmap(domain, hwirq);
 		generic_handle_irq(irq);
@@ -654,8 +791,10 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
 
 	gic_init(res.start, resource_size(&res), NULL, 0, MIPS_GIC_IRQ_BASE);
 
-	domain = irq_domain_add_legacy(node, GIC_NUM_INTRS, MIPS_GIC_IRQ_BASE,
-				       0, &gic_irq_domain_ops, NULL);
+	domain = irq_domain_add_legacy(node,
+				       GIC_NUM_INTRS + GIC_NUM_LOCAL_INTRS,
+				       MIPS_GIC_IRQ_BASE, 0,
+				       &gic_irq_domain_ops, NULL);
 	if (!domain) {
 		pr_err("Failed to add GIC IRQ domain\n");
 		return -ENOMEM;
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 11/12] MIPS: GIC: Use local interrupts for timer

[Andrew Bresticker]

Instead of using GIC interrupt 0 for the timer (which was not even
handled correctly by the GIC irqchip code and could conflict with an
actual external interrupt), use the designated local interrupt for
the GIC timer.

Also, since the timer is a per-CPU interrupt, initialize it with
setup_percpu_irq() and enable it with enable_percpu_irq() instead
of using direct register writes.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/kernel/cevt-gic.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/mips/kernel/cevt-gic.c b/arch/mips/kernel/cevt-gic.c
index 6093716..cae72a4 100644
--- a/arch/mips/kernel/cevt-gic.c
+++ b/arch/mips/kernel/cevt-gic.c
@@ -68,7 +68,7 @@ int gic_clockevent_init(void)
 	if (!cpu_has_counter || !gic_frequency)
 		return -ENXIO;
 
-	irq = MIPS_GIC_IRQ_BASE;
+	irq = MIPS_GIC_LOCAL_IRQ_BASE + GIC_LOCAL_INTR_COMPARE;
 
 	cd = &per_cpu(gic_clockevent_device, cpu);
 
@@ -91,15 +91,13 @@ int gic_clockevent_init(void)
 
 	clockevents_register_device(cd);
 
-	GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_COMPARE_MAP), 0x80000002);
-	GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_SMASK), GIC_VPE_SMASK_CMP_MSK);
+	if (!gic_timer_irq_installed) {
+		setup_percpu_irq(irq, &gic_compare_irqaction);
+		irq_set_handler(irq, handle_percpu_irq);
+		gic_timer_irq_installed = 1;
+	}
 
-	if (gic_timer_irq_installed)
-		return 0;
+	enable_percpu_irq(irq, 0);
 
-	gic_timer_irq_installed = 1;
-
-	setup_irq(irq, &gic_compare_irqaction);
-	irq_set_handler(irq, handle_percpu_irq);
 	return 0;
 }
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 12/12] MIPS: Malta: Map GIC local interrupts

[Andrew Bresticker]

Now that the GIC driver properly supports local interrupts, extend
the static interrupt mapping to include the GIC timer and watchdog
and fix up the GIC interrupt setup and handling so that the local
interrupts are properly handled.  Note that ipi_map is also renamed
to gic_irq_map since it is now also used to track mapping of non-IPI
interrupts to CPUs.

Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
---
 arch/mips/mti-malta/malta-int.c | 44 +++++++++++++++++++++++++++++++----------
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/mips/mti-malta/malta-int.c b/arch/mips/mti-malta/malta-int.c
index e4f43ba..16b1473 100644
--- a/arch/mips/mti-malta/malta-int.c
+++ b/arch/mips/mti-malta/malta-int.c
@@ -38,7 +38,7 @@
 #include <asm/rtlx.h>
 
 static unsigned long _msc01_biu_base;
-static unsigned int ipi_map[NR_CPUS];
+static unsigned int gic_irq_map[NR_CPUS];
 
 static DEFINE_RAW_SPINLOCK(mips_irq_lock);
 
@@ -129,8 +129,8 @@ static void malta_hw0_irqdispatch(void)
 
 static void malta_ipi_irqdispatch(void)
 {
-#ifdef CONFIG_MIPS_GIC_IPI
 	unsigned long irq;
+#ifdef CONFIG_MIPS_GIC_IPI
 	DECLARE_BITMAP(pending, GIC_NUM_INTRS);
 
 	gic_get_int_mask(pending, ipi_ints);
@@ -143,8 +143,12 @@ static void malta_ipi_irqdispatch(void)
 		irq = find_next_bit(pending, GIC_NUM_INTRS, irq + 1);
 	}
 #endif
-	if (gic_compare_int())
-		do_IRQ(MIPS_GIC_IRQ_BASE);
+	irq = gic_get_local_int();
+	while (irq < GIC_NUM_LOCAL_INTRS) {
+		do_IRQ(MIPS_GIC_LOCAL_IRQ_BASE + irq);
+
+		irq = gic_get_local_int();
+	}
 }
 
 static void corehi_irqdispatch(void)
@@ -288,7 +292,7 @@ asmlinkage void plat_irq_dispatch(void)
 
 	if (irq == MIPSCPU_INT_I8259A)
 		malta_hw0_irqdispatch();
-	else if (gic_present && ((1 << irq) & ipi_map[smp_processor_id()]))
+	else if (gic_present && ((1 << irq) & gic_irq_map[smp_processor_id()]))
 		malta_ipi_irqdispatch();
 	else
 		do_IRQ(MIPS_CPU_IRQ_BASE + irq);
@@ -408,7 +412,7 @@ static int msc_nr_eicirqs __initdata = ARRAY_SIZE(msc_eicirqmap);
 #define GIC_CPU_NMI GIC_MAP_TO_NMI_MSK
 #define X GIC_UNUSED
 
-static struct gic_intr_map gic_intr_map[GIC_NUM_INTRS] = {
+static struct gic_intr_map gic_intr_map[GIC_NUM_INTRS + GIC_NUM_LOCAL_INTRS] = {
 	{ X, X,		   X,		X,		0 },
 	{ X, X,		   X,		X,		0 },
 	{ X, X,		   X,		X,		0 },
@@ -425,7 +429,10 @@ static struct gic_intr_map gic_intr_map[GIC_NUM_INTRS] = {
 	{ 0, GIC_CPU_NMI,  GIC_POL_POS, GIC_TRIG_LEVEL, GIC_FLAG_TRANSPARENT },
 	{ 0, GIC_CPU_NMI,  GIC_POL_POS, GIC_TRIG_LEVEL, GIC_FLAG_TRANSPARENT },
 	{ X, X,		   X,		X,		0 },
-	/* The remainder of this table is initialised by fill_ipi_map */
+	/*
+	 * The remainder of this table is initialised by fill_ipi_map and
+	 * fill_local_irq_map
+	 */
 };
 #undef X
 
@@ -438,7 +445,7 @@ static void __init fill_ipi_map1(int baseintr, int cpu, int cpupin)
 	gic_intr_map[intr].polarity = GIC_POL_POS;
 	gic_intr_map[intr].trigtype = GIC_TRIG_EDGE;
 	gic_intr_map[intr].flags = 0;
-	ipi_map[cpu] |= (1 << (cpupin + 2));
+	gic_irq_map[cpu] |= (1 << (cpupin + 2));
 	bitmap_set(ipi_ints, intr, 1);
 }
 
@@ -453,6 +460,22 @@ static void __init fill_ipi_map(void)
 }
 #endif
 
+static void __init fill_local_irq_map(void)
+{
+	int i;
+
+	for (i = 0; i < GIC_NUM_LOCAL_INTRS; i++) {
+		int intr = i + GIC_NUM_INTRS;
+
+		gic_intr_map[intr].cpunum = 0;
+		gic_intr_map[intr].pin = GIC_CPU_INT2;
+		gic_intr_map[intr].flags = 0;
+	}
+
+	for (i = 0; i < NR_CPUS; i++)
+		gic_irq_map[i] |= 1 << (GIC_CPU_INT2 + 2);
+}
+
 void __init arch_init_ipiirq(int irq, struct irqaction *action)
 {
 	setup_irq(irq, action);
@@ -533,6 +556,7 @@ void __init arch_init_irq(void)
 		gic_resched_int_base = gic_call_int_base - nr_cpu_ids;
 		fill_ipi_map();
 #endif
+		fill_local_irq_map();
 		gic_init(GIC_BASE_ADDR, GIC_ADDRSPACE_SZ, gic_intr_map,
 				ARRAY_SIZE(gic_intr_map), MIPS_GIC_IRQ_BASE);
 		if (!mips_cm_present()) {
@@ -542,8 +566,7 @@ void __init arch_init_irq(void)
 				(i | (0x1 << MSC01_SC_CFG_GICENA_SHF));
 			pr_debug("GIC Enabled\n");
 		}
-#if defined(CONFIG_MIPS_GIC_IPI)
-		/* set up ipi interrupts */
+		/* set up ipi and local interrupts */
 		if (cpu_has_vint) {
 			set_vi_handler(MIPSCPU_INT_IPI0, malta_ipi_irqdispatch);
 			set_vi_handler(MIPSCPU_INT_IPI1, malta_ipi_irqdispatch);
@@ -557,6 +580,7 @@ void __init arch_init_irq(void)
 		write_c0_status(0x1100dc00);
 		pr_info("CPU%d: status register frc %08x\n",
 			smp_processor_id(), read_c0_status());
+#if defined(CONFIG_MIPS_GIC_IPI)
 		for (i = 0; i < nr_cpu_ids; i++) {
 			arch_init_ipiirq(MIPS_GIC_IRQ_BASE +
 					 GIC_RESCHED_INT(i), &irq_resched);
-- 
2.1.0.rc2.206.gedb03e5

Re: [PATCH 00/12] MIPS: GIC device-tree support

[John Crispin]

Hi Andrew,

On 30/08/2014 00:14, Andrew Bresticker wrote:
> Based on 3.17-rc2 and boot tested on Danube (+ out of tree patches) and
> Malta.

Lantiq makes a mips soc called danube. is this the same family or is
this just a name collision between 2 chip vendors ?

	John

Re: [PATCH 00/12] MIPS: GIC device-tree support

[John Crispin]

Hi Andrew,

On 30/08/2014 00:14, Andrew Bresticker wrote:
> Based on 3.17-rc2 and boot tested on Danube (+ out of tree patches) and
> Malta.

Lantiq makes a mips soc called danube. is this the same family or is
this just a name collision between 2 chip vendors ?

	John
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Arnd Bergmann]

On Friday 29 August 2014 15:14:30 Andrew Bresticker wrote:
> The Global Interrupt Controller (GIC) present on certain MIPS systems
> can be used to route external interrupts to individual VPEs and CPU
> interrupt vectors.  It also supports a timer and software-generated
> interrupts.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> ---
>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
> 

This may be a stupid question, but is this related to the ARM GIC
in any way or does it just share the name?

In either case the binding belongs into
Documentation/devicetree/bindings/interrupt-controller/.

The ARM one should be moved there as well, and then we have
to come up with a new name for the files when there is a conflict.


	Arnd

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Arnd Bergmann]

On Friday 29 August 2014 15:14:30 Andrew Bresticker wrote:
> The Global Interrupt Controller (GIC) present on certain MIPS systems
> can be used to route external interrupts to individual VPEs and CPU
> interrupt vectors.  It also supports a timer and software-generated
> interrupts.
> 
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
> 

This may be a stupid question, but is this related to the ARM GIC
in any way or does it just share the name?

In either case the binding belongs into
Documentation/devicetree/bindings/interrupt-controller/.

The ARM one should be moved there as well, and then we have
to come up with a new name for the files when there is a conflict.


	Arnd
--
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

Re: [PATCH 05/12] MIPS: GIC: Add device-tree support

[Arnd Bergmann]

On Friday 29 August 2014 15:14:32 Andrew Bresticker wrote:
> Add device-tree support for the MIPS GIC.  With DT, no per-platform
> static device interrupt mapping is supplied and instead all device
> interrupts are specified through the DT.  The GIC-to-CPU interrupts
> must also be specified in the DT.
> 
> Platforms using DT-based probing of the GIC need only supply the
> GIC_NUM_INTRS and, if necessary, MIPS_GIC_IRQ_BASE values and
> call of_irq_init() with an of_device_id table including the GIC.
> 
> Currenlty only legacy and vecotred interrupt modes are supported.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> ---
>  arch/mips/include/asm/gic.h |  15 ++++++
>  arch/mips/kernel/irq-gic.c  | 122 +++++++++++++++++++++++++++++++++++++++++++-
> 


Can you move this to drivers/irqchip and use the IRQCHIP_DECLARE()
macro to define the entry point?

	Arnd

Re: [PATCH 05/12] MIPS: GIC: Add device-tree support

[Arnd Bergmann]

On Friday 29 August 2014 15:14:32 Andrew Bresticker wrote:
> Add device-tree support for the MIPS GIC.  With DT, no per-platform
> static device interrupt mapping is supplied and instead all device
> interrupts are specified through the DT.  The GIC-to-CPU interrupts
> must also be specified in the DT.
> 
> Platforms using DT-based probing of the GIC need only supply the
> GIC_NUM_INTRS and, if necessary, MIPS_GIC_IRQ_BASE values and
> call of_irq_init() with an of_device_id table including the GIC.
> 
> Currenlty only legacy and vecotred interrupt modes are supported.
> 
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>  arch/mips/include/asm/gic.h |  15 ++++++
>  arch/mips/kernel/irq-gic.c  | 122 +++++++++++++++++++++++++++++++++++++++++++-
> 


Can you move this to drivers/irqchip and use the IRQCHIP_DECLARE()
macro to define the entry point?

	Arnd
--
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

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Arnd Bergmann]

On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> 

Why do you actually have to hardwire an IRQ base? Can't you move
to the linear irqdomain code for DT based MIPS systems yet?

	Arnd

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Arnd Bergmann]

On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
> 
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> 

Why do you actually have to hardwire an IRQ base? Can't you move
to the linear irqdomain code for DT based MIPS systems yet?

	Arnd
--
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

Re: [PATCH 01/12] MIPS: Provide a generic plat_irq_dispatch

[Jonas Gorski]

On Sat, Aug 30, 2014 at 12:14 AM, Andrew Bresticker
<abrestic@chromium.org> wrote:
> For platforms which boot with device-tree and use the MIPS CPU interrupt
> controller binding, a generic plat_irq_dispatch() can be used since all
> CPU interrupts should be mapped through the CPU IRQ domain.  Implement a
> plat_irq_dispatch() which simply handles the highest pending interrupt.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>

I gave this a short test by hackishly adding IRQ_DOMAIN support to
bcm63xx and removing the local plat_irq_dispatch, and it booted fine,
and cascaded interrupts were still working. Therefore

Tested-by: Jonas Gorski <jogo@openwrt.org>


Jonas

Re: [PATCH 01/12] MIPS: Provide a generic plat_irq_dispatch

[Jonas Gorski]

On Sat, Aug 30, 2014 at 12:14 AM, Andrew Bresticker
<abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> For platforms which boot with device-tree and use the MIPS CPU interrupt
> controller binding, a generic plat_irq_dispatch() can be used since all
> CPU interrupts should be mapped through the CPU IRQ domain.  Implement a
> plat_irq_dispatch() which simply handles the highest pending interrupt.
>
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

I gave this a short test by hackishly adding IRQ_DOMAIN support to
bcm63xx and removing the local plat_irq_dispatch, and it booted fine,
and cascaded interrupts were still working. Therefore

Tested-by: Jonas Gorski <jogo-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>


Jonas
--
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

Re: [PATCH 00/12] MIPS: GIC device-tree support

[Andrew Bresticker]

On Fri, Aug 29, 2014 at 11:33 PM, John Crispin <blogic@openwrt.org> wrote:
> Hi Andrew,
>
> On 30/08/2014 00:14, Andrew Bresticker wrote:
>> Based on 3.17-rc2 and boot tested on Danube (+ out of tree patches) and
>> Malta.
>
> Lantiq makes a mips soc called danube. is this the same family or is
> this just a name collision between 2 chip vendors ?

They are unrelated.  It's just a name collision.

Re: [PATCH 00/12] MIPS: GIC device-tree support

[Andrew Bresticker]

On Fri, Aug 29, 2014 at 11:33 PM, John Crispin <blogic-p3rKhJxN3npAfugRpC6u6w@public.gmane.org> wrote:
> Hi Andrew,
>
> On 30/08/2014 00:14, Andrew Bresticker wrote:
>> Based on 3.17-rc2 and boot tested on Danube (+ out of tree patches) and
>> Malta.
>
> Lantiq makes a mips soc called danube. is this the same family or is
> this just a name collision between 2 chip vendors ?

They are unrelated.  It's just a name collision.
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Sat, Aug 30, 2014 at 12:53 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 29 August 2014 15:14:30 Andrew Bresticker wrote:
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors.  It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> ---
>>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>>
>
> This may be a stupid question, but is this related to the ARM GIC
> in any way or does it just share the name?

There's no relation.  Note that it's also "Global Interrupt
Controller" vs. "Generic Interrupt Controller".

> In either case the binding belongs into
> Documentation/devicetree/bindings/interrupt-controller/.

Will do.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Sat, Aug 30, 2014 at 12:53 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday 29 August 2014 15:14:30 Andrew Bresticker wrote:
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors.  It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>>
>
> This may be a stupid question, but is this related to the ARM GIC
> in any way or does it just share the name?

There's no relation.  Note that it's also "Global Interrupt
Controller" vs. "Generic Interrupt Controller".

> In either case the binding belongs into
> Documentation/devicetree/bindings/interrupt-controller/.

Will do.
--
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

Re: [PATCH 05/12] MIPS: GIC: Add device-tree support

[Andrew Bresticker]

On Sat, Aug 30, 2014 at 12:54 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 29 August 2014 15:14:32 Andrew Bresticker wrote:
>> Add device-tree support for the MIPS GIC.  With DT, no per-platform
>> static device interrupt mapping is supplied and instead all device
>> interrupts are specified through the DT.  The GIC-to-CPU interrupts
>> must also be specified in the DT.
>>
>> Platforms using DT-based probing of the GIC need only supply the
>> GIC_NUM_INTRS and, if necessary, MIPS_GIC_IRQ_BASE values and
>> call of_irq_init() with an of_device_id table including the GIC.
>>
>> Currenlty only legacy and vecotred interrupt modes are supported.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> ---
>>  arch/mips/include/asm/gic.h |  15 ++++++
>>  arch/mips/kernel/irq-gic.c  | 122 +++++++++++++++++++++++++++++++++++++++++++-
>>
>
>
> Can you move this to drivers/irqchip and use the IRQCHIP_DECLARE()
> macro to define the entry point?

Sure.  I was planning on doing this later, but I don't see why it
couldn't be done now though.

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Andrew Bresticker]

On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
>> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
>> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
>> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
>> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>
>
> Why do you actually have to hardwire an IRQ base? Can't you move
> to the linear irqdomain code for DT based MIPS systems yet?

Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
still require a hard-coded IRQ base.  For boards using device-tree, I
stuck with a legacy IRQ domain as it allows most of the existing GIC
irqchip code to be reused.

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Arnd Bergmann]

On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote:
> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
> >> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
> >> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
> >> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
> >> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>
> >
> > Why do you actually have to hardwire an IRQ base? Can't you move
> > to the linear irqdomain code for DT based MIPS systems yet?
> 
> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
> still require a hard-coded IRQ base.  For boards using device-tree, I
> stuck with a legacy IRQ domain as it allows most of the existing GIC
> irqchip code to be reused.

I see. Note that we now have irq_domain_add_simple(), which should
do the right think in either case: use a legacy domain when a 
nonzero base is provided for the old boards, but use the simple
domain when probed from DT without an irq base.

This makes the latter case more memory efficient (it avoids
allocating the irq descriptors for every possibly but unused
IRQ number) and helps ensure that you don't accidentally rely
on hardcoded IRQ numbers for the DT based machines, which would
be considered a bug.

	Arnd

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Arnd Bergmann]

On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote:
> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
> >> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
> >> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
> >> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
> >> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >>
> >
> > Why do you actually have to hardwire an IRQ base? Can't you move
> > to the linear irqdomain code for DT based MIPS systems yet?
> 
> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
> still require a hard-coded IRQ base.  For boards using device-tree, I
> stuck with a legacy IRQ domain as it allows most of the existing GIC
> irqchip code to be reused.

I see. Note that we now have irq_domain_add_simple(), which should
do the right think in either case: use a legacy domain when a 
nonzero base is provided for the old boards, but use the simple
domain when probed from DT without an irq base.

This makes the latter case more memory efficient (it avoids
allocating the irq descriptors for every possibly but unused
IRQ number) and helps ensure that you don't accidentally rely
on hardcoded IRQ numbers for the DT based machines, which would
be considered a bug.

	Arnd
--
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

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[John Crispin]

On 01/09/2014 10:34, Arnd Bergmann wrote:
> On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote:
>> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
>>>> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
>>>> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
>>>> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
>>>> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
>>>>
>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>>
>>>
>>> Why do you actually have to hardwire an IRQ base? Can't you move
>>> to the linear irqdomain code for DT based MIPS systems yet?
>>
>> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
>> still require a hard-coded IRQ base.  For boards using device-tree, I
>> stuck with a legacy IRQ domain as it allows most of the existing GIC
>> irqchip code to be reused.
> 
> I see. Note that we now have irq_domain_add_simple(), which should
> do the right think in either case: use a legacy domain when a 
> nonzero base is provided for the old boards, but use the simple
> domain when probed from DT without an irq base.
> 
> This makes the latter case more memory efficient (it avoids
> allocating the irq descriptors for every possibly but unused
> IRQ number) and helps ensure that you don't accidentally rely
> on hardcoded IRQ numbers for the DT based machines, which would
> be considered a bug.

Hi,

for the mediatek mt7621/1004k we use the following code to load the gic
https://dev.openwrt.org/browser/trunk/target/linux/ramips/patches-3.14/0012-MIPS-ralink-add-MT7621-support.patch
 (look for  arch/mips/ralink/irq-gic.c)

we ended up using irq_domain_add_legacy()

i am planning to send these patches upstream in the near future.

	John

	John


> 
> 	Arnd
> 
> 

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Mark Rutland]

On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
> The Global Interrupt Controller (GIC) present on certain MIPS systems
> can be used to route external interrupts to individual VPEs and CPU
> interrupt vectors.  It also supports a timer and software-generated
> interrupts.
> 
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> ---
>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
> new file mode 100644
> index 0000000..725f1ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> @@ -0,0 +1,50 @@
> +MIPS Global Interrupt Controller (GIC)
> +
> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> +It also supports a timer and software-generated interrupts which can be
> +used as IPIs.
> +
> +Required properties:
> +- compatible : Should be "mti,global-interrupt-controller"

I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
there's not a patch to add it elsewhere, would you mind providing one
with this series?

> +- reg : Base address and length of the GIC registers.
> +- interrupts : Core interrupts to which the GIC may route external interrupts.

How many? in any order?

> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt specifier.  Should be 3.
> +  - The first cell is the GIC interrupt number.
> +  - The second cell encodes the interrupt flags.
> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
> +    flags.

Are all the flags valid for this interrupt controller?

> +  - The optional third cell indicates which CPU interrupt vector the GIC
> +    interrupt should be routed to.  It is a 0-based index into the list of
> +    GIC-to-CPU interrupts specified in the "interrupts" property described
> +    above.  For example, a '2' in this cell will route the interrupt to the
> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
> +    be routed to the 1st core interrupt.

I don't follow why this should be in the DT. Why is this necessary?

I also don't follow how this can be ommitted, given interrupt-cells is
required to be three by the wording above.

> +
> +Example:
> +
> +	cpu_intc: interrupt-controller@0 {

Nit: there's no reg on this node, so there shouldn't be a unit-address.

Thanks,
Mark.

> +		compatible = "mti,cpu-interrupt-controller";
> +
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +	};
> +
> +	gic: interrupt-controller@1bdc0000 {
> +		compatible = "mti,global-interrupt-controller";
> +		reg = <0x1bdc0000 0x20000>;
> +
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +
> +		interrupt-parent = <&cpu_intc>;
> +		interrupts = <3>, <4>;
> +	};
> +
> +	uart@18101400 {
> +		...
> +		interrupt-parent = <&gic>;
> +		interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
> +		...
> +	};
> -- 
> 2.1.0.rc2.206.gedb03e5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Mark Rutland]

On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
> The Global Interrupt Controller (GIC) present on certain MIPS systems
> can be used to route external interrupts to individual VPEs and CPU
> interrupt vectors.  It also supports a timer and software-generated
> interrupts.
> 
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
> new file mode 100644
> index 0000000..725f1ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> @@ -0,0 +1,50 @@
> +MIPS Global Interrupt Controller (GIC)
> +
> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> +It also supports a timer and software-generated interrupts which can be
> +used as IPIs.
> +
> +Required properties:
> +- compatible : Should be "mti,global-interrupt-controller"

I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
there's not a patch to add it elsewhere, would you mind providing one
with this series?

> +- reg : Base address and length of the GIC registers.
> +- interrupts : Core interrupts to which the GIC may route external interrupts.

How many? in any order?

> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt specifier.  Should be 3.
> +  - The first cell is the GIC interrupt number.
> +  - The second cell encodes the interrupt flags.
> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
> +    flags.

Are all the flags valid for this interrupt controller?

> +  - The optional third cell indicates which CPU interrupt vector the GIC
> +    interrupt should be routed to.  It is a 0-based index into the list of
> +    GIC-to-CPU interrupts specified in the "interrupts" property described
> +    above.  For example, a '2' in this cell will route the interrupt to the
> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
> +    be routed to the 1st core interrupt.

I don't follow why this should be in the DT. Why is this necessary?

I also don't follow how this can be ommitted, given interrupt-cells is
required to be three by the wording above.

> +
> +Example:
> +
> +	cpu_intc: interrupt-controller@0 {

Nit: there's no reg on this node, so there shouldn't be a unit-address.

Thanks,
Mark.

> +		compatible = "mti,cpu-interrupt-controller";
> +
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +	};
> +
> +	gic: interrupt-controller@1bdc0000 {
> +		compatible = "mti,global-interrupt-controller";
> +		reg = <0x1bdc0000 0x20000>;
> +
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +
> +		interrupt-parent = <&cpu_intc>;
> +		interrupts = <3>, <4>;
> +	};
> +
> +	uart@18101400 {
> +		...
> +		interrupt-parent = <&gic>;
> +		interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
> +		...
> +	};
> -- 
> 2.1.0.rc2.206.gedb03e5
> 
> --
> 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
> 
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[James Hogan]

On 01/09/14 12:01, Mark Rutland wrote:
> On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
> 
> I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> there's not a patch to add it elsewhere, would you mind providing one
> with this series?

It should be noted that there does already exist an "img" prefix in that
file which may be more suitable (mti stands for MIPS Technologies Inc.).

Though of course it appears the mti prefix is already in use, like
"mti,cpu-interrupt-controller" in the binding example.

Cheers
James

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[James Hogan]

On 01/09/14 12:01, Mark Rutland wrote:
> On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
> 
> I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> there's not a patch to add it elsewhere, would you mind providing one
> with this series?

It should be noted that there does already exist an "img" prefix in that
file which may be more suitable (mti stands for MIPS Technologies Inc.).

Though of course it appears the mti prefix is already in use, like
"mti,cpu-interrupt-controller" in the binding example.

Cheers
James
--
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

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Andrew Bresticker]

On Mon, Sep 1, 2014 at 1:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote:
>> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
>> >> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
>> >> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
>> >> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
>> >> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> >>
>> >
>> > Why do you actually have to hardwire an IRQ base? Can't you move
>> > to the linear irqdomain code for DT based MIPS systems yet?
>>
>> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
>> still require a hard-coded IRQ base.  For boards using device-tree, I
>> stuck with a legacy IRQ domain as it allows most of the existing GIC
>> irqchip code to be reused.
>
> I see. Note that we now have irq_domain_add_simple(), which should
> do the right think in either case: use a legacy domain when a
> nonzero base is provided for the old boards, but use the simple
> domain when probed from DT without an irq base.
>
> This makes the latter case more memory efficient (it avoids
> allocating the irq descriptors for every possibly but unused
> IRQ number) and helps ensure that you don't accidentally rely
> on hardcoded IRQ numbers for the DT based machines, which would
> be considered a bug.

Ah, ok.  It looks like add_simple() is what I want then.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors.  It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> ---
>>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>>  1 file changed, 50 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
>> new file mode 100644
>> index 0000000..725f1ef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> @@ -0,0 +1,50 @@
>> +MIPS Global Interrupt Controller (GIC)
>> +
>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> +It also supports a timer and software-generated interrupts which can be
>> +used as IPIs.
>> +
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
>
> I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> there's not a patch to add it elsewhere, would you mind providing one
> with this series?

Sure.  As James points out, "img" could also be used but I chose "mti"
since the CPU interrupt controller also uses "mti" and I believe the
GIC IP was developed before the acquisition by Imagination (though I'm
not sure if that actually matters).

>> +- reg : Base address and length of the GIC registers.
>> +- interrupts : Core interrupts to which the GIC may route external interrupts.
>
> How many?

Up to 6, one for each of the possible core hardware interrupts (i.e.
interrupt vectors 2 - 7).  Which ones are available to the GIC depend
on the system, for example Malta has an i8259 PIC hooked up to CPU
interrupt vector 2, so that vector should not be used by the GIC.

> In any order?

They can technically be in any order, but when in strictly
increasing/decreasing order they can be used along with the 3rd cell
(described below) to prioritize interrupts.

>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt specifier.  Should be 3.
>> +  - The first cell is the GIC interrupt number.
>> +  - The second cell encodes the interrupt flags.
>> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
>> +    flags.
>
> Are all the flags valid for this interrupt controller?

Yes.

>> +  - The optional third cell indicates which CPU interrupt vector the GIC
>> +    interrupt should be routed to.  It is a 0-based index into the list of
>> +    GIC-to-CPU interrupts specified in the "interrupts" property described
>> +    above.  For example, a '2' in this cell will route the interrupt to the
>> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
>> +    be routed to the 1st core interrupt.
>
> I don't follow why this should be in the DT. Why is this necessary?

Since the GIC can route external interrupts to any of the CPU hardware
interrupt vectors, it can be used to assign priorities to external
interrupts.  If the CPU is in vectored interrupt mode, the highest
numbered interrupt vector (7) has the highest priority.  An example:

gic: interrupt-controller@1bdc0000 {
        ...
        interrupts = <3>, <4>;
        ...
};

uart {
        ...
        interrupt-parent = <&gic>;
        interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
        ...
};

i2c {
        ...
        interrupt-parent = <&gic>;
        interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
        ...
};

Since the third cell for the UART is '1', it maps to CPU interrupt
vector 4 and thus has a higher priority than the I2C (whose third cell
is 0, mapping to CPU interrupt vector 3).

Perhaps, though, this is an instance of software policy being
specified in device-tree.  Other options would be to a) evenly
distribute the GIC external interrupts across the CPU interrupt
vectors available to the GIC, or b) just map all GIC external
interrupts to a single interrupt vector.

> I also don't follow how this can be ommitted, given interrupt-cells is
> required to be three by the wording above.

If it's absent, the interrupt will be routed to the first CPU
interrupt vector in the list.  It's equivalent to the third cell being
0.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors.  It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>>  1 file changed, 50 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
>> new file mode 100644
>> index 0000000..725f1ef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> @@ -0,0 +1,50 @@
>> +MIPS Global Interrupt Controller (GIC)
>> +
>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> +It also supports a timer and software-generated interrupts which can be
>> +used as IPIs.
>> +
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
>
> I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> there's not a patch to add it elsewhere, would you mind providing one
> with this series?

Sure.  As James points out, "img" could also be used but I chose "mti"
since the CPU interrupt controller also uses "mti" and I believe the
GIC IP was developed before the acquisition by Imagination (though I'm
not sure if that actually matters).

>> +- reg : Base address and length of the GIC registers.
>> +- interrupts : Core interrupts to which the GIC may route external interrupts.
>
> How many?

Up to 6, one for each of the possible core hardware interrupts (i.e.
interrupt vectors 2 - 7).  Which ones are available to the GIC depend
on the system, for example Malta has an i8259 PIC hooked up to CPU
interrupt vector 2, so that vector should not be used by the GIC.

> In any order?

They can technically be in any order, but when in strictly
increasing/decreasing order they can be used along with the 3rd cell
(described below) to prioritize interrupts.

>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt specifier.  Should be 3.
>> +  - The first cell is the GIC interrupt number.
>> +  - The second cell encodes the interrupt flags.
>> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
>> +    flags.
>
> Are all the flags valid for this interrupt controller?

Yes.

>> +  - The optional third cell indicates which CPU interrupt vector the GIC
>> +    interrupt should be routed to.  It is a 0-based index into the list of
>> +    GIC-to-CPU interrupts specified in the "interrupts" property described
>> +    above.  For example, a '2' in this cell will route the interrupt to the
>> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
>> +    be routed to the 1st core interrupt.
>
> I don't follow why this should be in the DT. Why is this necessary?

Since the GIC can route external interrupts to any of the CPU hardware
interrupt vectors, it can be used to assign priorities to external
interrupts.  If the CPU is in vectored interrupt mode, the highest
numbered interrupt vector (7) has the highest priority.  An example:

gic: interrupt-controller@1bdc0000 {
        ...
        interrupts = <3>, <4>;
        ...
};

uart {
        ...
        interrupt-parent = <&gic>;
        interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
        ...
};

i2c {
        ...
        interrupt-parent = <&gic>;
        interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
        ...
};

Since the third cell for the UART is '1', it maps to CPU interrupt
vector 4 and thus has a higher priority than the I2C (whose third cell
is 0, mapping to CPU interrupt vector 3).

Perhaps, though, this is an instance of software policy being
specified in device-tree.  Other options would be to a) evenly
distribute the GIC external interrupts across the CPU interrupt
vectors available to the GIC, or b) just map all GIC external
interrupts to a single interrupt vector.

> I also don't follow how this can be ommitted, given interrupt-cells is
> required to be three by the wording above.

If it's absent, the interrupt will be routed to the first CPU
interrupt vector in the list.  It's equivalent to the third cell being
0.
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Mark Rutland]

On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:
> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
> >> The Global Interrupt Controller (GIC) present on certain MIPS systems
> >> can be used to route external interrupts to individual VPEs and CPU
> >> interrupt vectors.  It also supports a timer and software-generated
> >> interrupts.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >> ---
> >>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
> >>  1 file changed, 50 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
> >> new file mode 100644
> >> index 0000000..725f1ef
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> >> @@ -0,0 +1,50 @@
> >> +MIPS Global Interrupt Controller (GIC)
> >> +
> >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> >> +It also supports a timer and software-generated interrupts which can be
> >> +used as IPIs.
> >> +
> >> +Required properties:
> >> +- compatible : Should be "mti,global-interrupt-controller"
> >
> > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> > there's not a patch to add it elsewhere, would you mind providing one
> > with this series?
> 
> Sure.  As James points out, "img" could also be used but I chose "mti"
> since the CPU interrupt controller also uses "mti" and I believe the
> GIC IP was developed before the acquisition by Imagination (though I'm
> not sure if that actually matters).

Using 'mti' sounds like the right choice to me given both of those
points.

> >> +- reg : Base address and length of the GIC registers.
> >> +- interrupts : Core interrupts to which the GIC may route external interrupts.
> >
> > How many?
> 
> Up to 6, one for each of the possible core hardware interrupts (i.e.
> interrupt vectors 2 - 7).  Which ones are available to the GIC depend
> on the system, for example Malta has an i8259 PIC hooked up to CPU
> interrupt vector 2, so that vector should not be used by the GIC.
> 
> > In any order?
> 
> They can technically be in any order, but when in strictly
> increasing/decreasing order they can be used along with the 3rd cell
> (described below) to prioritize interrupts.

Ok. Could you try to place that into the property description?

> >> +- interrupt-controller : Identifies the node as an interrupt controller
> >> +- #interrupt-cells : Specifies the number of cells needed to encode an
> >> +  interrupt specifier.  Should be 3.
> >> +  - The first cell is the GIC interrupt number.
> >> +  - The second cell encodes the interrupt flags.
> >> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
> >> +    flags.
> >
> > Are all the flags valid for this interrupt controller?
> 
> Yes.

Ok.

> >> +  - The optional third cell indicates which CPU interrupt vector the GIC
> >> +    interrupt should be routed to.  It is a 0-based index into the list of
> >> +    GIC-to-CPU interrupts specified in the "interrupts" property described
> >> +    above.  For example, a '2' in this cell will route the interrupt to the
> >> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
> >> +    be routed to the 1st core interrupt.
> >
> > I don't follow why this should be in the DT. Why is this necessary?
> 
> Since the GIC can route external interrupts to any of the CPU hardware
> interrupt vectors, it can be used to assign priorities to external
> interrupts.  If the CPU is in vectored interrupt mode, the highest
> numbered interrupt vector (7) has the highest priority.  An example:
> 
> gic: interrupt-controller@1bdc0000 {
>         ...
>         interrupts = <3>, <4>;
>         ...
> };
> 
> uart {
>         ...
>         interrupt-parent = <&gic>;
>         interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
>         ...
> };
> 
> i2c {
>         ...
>         interrupt-parent = <&gic>;
>         interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
>         ...
> };
> 
> Since the third cell for the UART is '1', it maps to CPU interrupt
> vector 4 and thus has a higher priority than the I2C (whose third cell
> is 0, mapping to CPU interrupt vector 3).
> 
> Perhaps, though, this is an instance of software policy being
> specified in device-tree.  Other options would be to a) evenly
> distribute the GIC external interrupts across the CPU interrupt
> vectors available to the GIC, or b) just map all GIC external
> interrupts to a single interrupt vector.

As a user I don't see why the DT author should be in charge of whether
my UART gets higher priority than my I2C controller. That priority is
not a fixed property of the interrupt (as the line and flags are).

That said, this is a grey area. Are there any cases where this
prioritisation is critical on existing devices?

> > I also don't follow how this can be ommitted, given interrupt-cells is
> > required to be three by the wording above.
> 
> If it's absent, the interrupt will be routed to the first CPU
> interrupt vector in the list.  It's equivalent to the third cell being
> 0.

My point is that the wording implies that the third cell is optional on
a per-interrupt basis, when in reality it depends on the GIC node's
#interrupt-cells and affect all devices with GIC interrupts.

If &gic/#interrupt-cells = <3>, the third cell can't be absent.

If &gic/interrupt-cells = <2>, the third cell can't be present.

So it would be better to describe as something like:

  When interrupt-cells = <3>, the third cell specifies the priority (in
  the range X to Y). When #interrupt-cells = <2> all interrupts are
  assigned the same priority (Z).

Thanks,
Mark.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Mark Rutland]

On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:
> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
> >> The Global Interrupt Controller (GIC) present on certain MIPS systems
> >> can be used to route external interrupts to individual VPEs and CPU
> >> interrupt vectors.  It also supports a timer and software-generated
> >> interrupts.
> >>
> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >> ---
> >>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
> >>  1 file changed, 50 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
> >> new file mode 100644
> >> index 0000000..725f1ef
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> >> @@ -0,0 +1,50 @@
> >> +MIPS Global Interrupt Controller (GIC)
> >> +
> >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> >> +It also supports a timer and software-generated interrupts which can be
> >> +used as IPIs.
> >> +
> >> +Required properties:
> >> +- compatible : Should be "mti,global-interrupt-controller"
> >
> > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> > there's not a patch to add it elsewhere, would you mind providing one
> > with this series?
> 
> Sure.  As James points out, "img" could also be used but I chose "mti"
> since the CPU interrupt controller also uses "mti" and I believe the
> GIC IP was developed before the acquisition by Imagination (though I'm
> not sure if that actually matters).

Using 'mti' sounds like the right choice to me given both of those
points.

> >> +- reg : Base address and length of the GIC registers.
> >> +- interrupts : Core interrupts to which the GIC may route external interrupts.
> >
> > How many?
> 
> Up to 6, one for each of the possible core hardware interrupts (i.e.
> interrupt vectors 2 - 7).  Which ones are available to the GIC depend
> on the system, for example Malta has an i8259 PIC hooked up to CPU
> interrupt vector 2, so that vector should not be used by the GIC.
> 
> > In any order?
> 
> They can technically be in any order, but when in strictly
> increasing/decreasing order they can be used along with the 3rd cell
> (described below) to prioritize interrupts.

Ok. Could you try to place that into the property description?

> >> +- interrupt-controller : Identifies the node as an interrupt controller
> >> +- #interrupt-cells : Specifies the number of cells needed to encode an
> >> +  interrupt specifier.  Should be 3.
> >> +  - The first cell is the GIC interrupt number.
> >> +  - The second cell encodes the interrupt flags.
> >> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
> >> +    flags.
> >
> > Are all the flags valid for this interrupt controller?
> 
> Yes.

Ok.

> >> +  - The optional third cell indicates which CPU interrupt vector the GIC
> >> +    interrupt should be routed to.  It is a 0-based index into the list of
> >> +    GIC-to-CPU interrupts specified in the "interrupts" property described
> >> +    above.  For example, a '2' in this cell will route the interrupt to the
> >> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
> >> +    be routed to the 1st core interrupt.
> >
> > I don't follow why this should be in the DT. Why is this necessary?
> 
> Since the GIC can route external interrupts to any of the CPU hardware
> interrupt vectors, it can be used to assign priorities to external
> interrupts.  If the CPU is in vectored interrupt mode, the highest
> numbered interrupt vector (7) has the highest priority.  An example:
> 
> gic: interrupt-controller@1bdc0000 {
>         ...
>         interrupts = <3>, <4>;
>         ...
> };
> 
> uart {
>         ...
>         interrupt-parent = <&gic>;
>         interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
>         ...
> };
> 
> i2c {
>         ...
>         interrupt-parent = <&gic>;
>         interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
>         ...
> };
> 
> Since the third cell for the UART is '1', it maps to CPU interrupt
> vector 4 and thus has a higher priority than the I2C (whose third cell
> is 0, mapping to CPU interrupt vector 3).
> 
> Perhaps, though, this is an instance of software policy being
> specified in device-tree.  Other options would be to a) evenly
> distribute the GIC external interrupts across the CPU interrupt
> vectors available to the GIC, or b) just map all GIC external
> interrupts to a single interrupt vector.

As a user I don't see why the DT author should be in charge of whether
my UART gets higher priority than my I2C controller. That priority is
not a fixed property of the interrupt (as the line and flags are).

That said, this is a grey area. Are there any cases where this
prioritisation is critical on existing devices?

> > I also don't follow how this can be ommitted, given interrupt-cells is
> > required to be three by the wording above.
> 
> If it's absent, the interrupt will be routed to the first CPU
> interrupt vector in the list.  It's equivalent to the third cell being
> 0.

My point is that the wording implies that the third cell is optional on
a per-interrupt basis, when in reality it depends on the GIC node's
#interrupt-cells and affect all devices with GIC interrupts.

If &gic/#interrupt-cells = <3>, the third cell can't be absent.

If &gic/interrupt-cells = <2>, the third cell can't be present.

So it would be better to describe as something like:

  When interrupt-cells = <3>, the third cell specifies the priority (in
  the range X to Y). When #interrupt-cells = <2> all interrupts are
  assigned the same priority (Z).

Thanks,
Mark.
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Tue, Sep 2, 2014 at 2:33 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:
>> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> >> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> >> can be used to route external interrupts to individual VPEs and CPU
>> >> interrupt vectors.  It also supports a timer and software-generated
>> >> interrupts.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> >> ---
>> >>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>> >>  1 file changed, 50 insertions(+)
>> >>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
>> >> new file mode 100644
>> >> index 0000000..725f1ef
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> >> @@ -0,0 +1,50 @@
>> >> +MIPS Global Interrupt Controller (GIC)
>> >> +
>> >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> >> +It also supports a timer and software-generated interrupts which can be
>> >> +used as IPIs.
>> >> +
>> >> +Required properties:
>> >> +- compatible : Should be "mti,global-interrupt-controller"
>> >
>> > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
>> > there's not a patch to add it elsewhere, would you mind providing one
>> > with this series?
>>
>> Sure.  As James points out, "img" could also be used but I chose "mti"
>> since the CPU interrupt controller also uses "mti" and I believe the
>> GIC IP was developed before the acquisition by Imagination (though I'm
>> not sure if that actually matters).
>
> Using 'mti' sounds like the right choice to me given both of those
> points.
>
>> >> +- reg : Base address and length of the GIC registers.
>> >> +- interrupts : Core interrupts to which the GIC may route external interrupts.
>> >
>> > How many?
>>
>> Up to 6, one for each of the possible core hardware interrupts (i.e.
>> interrupt vectors 2 - 7).  Which ones are available to the GIC depend
>> on the system, for example Malta has an i8259 PIC hooked up to CPU
>> interrupt vector 2, so that vector should not be used by the GIC.
>>
>> > In any order?
>>
>> They can technically be in any order, but when in strictly
>> increasing/decreasing order they can be used along with the 3rd cell
>> (described below) to prioritize interrupts.
>
> Ok. Could you try to place that into the property description?
>
>> >> +- interrupt-controller : Identifies the node as an interrupt controller
>> >> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> >> +  interrupt specifier.  Should be 3.
>> >> +  - The first cell is the GIC interrupt number.
>> >> +  - The second cell encodes the interrupt flags.
>> >> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
>> >> +    flags.
>> >
>> > Are all the flags valid for this interrupt controller?
>>
>> Yes.
>
> Ok.
>
>> >> +  - The optional third cell indicates which CPU interrupt vector the GIC
>> >> +    interrupt should be routed to.  It is a 0-based index into the list of
>> >> +    GIC-to-CPU interrupts specified in the "interrupts" property described
>> >> +    above.  For example, a '2' in this cell will route the interrupt to the
>> >> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
>> >> +    be routed to the 1st core interrupt.
>> >
>> > I don't follow why this should be in the DT. Why is this necessary?
>>
>> Since the GIC can route external interrupts to any of the CPU hardware
>> interrupt vectors, it can be used to assign priorities to external
>> interrupts.  If the CPU is in vectored interrupt mode, the highest
>> numbered interrupt vector (7) has the highest priority.  An example:
>>
>> gic: interrupt-controller@1bdc0000 {
>>         ...
>>         interrupts = <3>, <4>;
>>         ...
>> };
>>
>> uart {
>>         ...
>>         interrupt-parent = <&gic>;
>>         interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
>>         ...
>> };
>>
>> i2c {
>>         ...
>>         interrupt-parent = <&gic>;
>>         interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
>>         ...
>> };
>>
>> Since the third cell for the UART is '1', it maps to CPU interrupt
>> vector 4 and thus has a higher priority than the I2C (whose third cell
>> is 0, mapping to CPU interrupt vector 3).
>>
>> Perhaps, though, this is an instance of software policy being
>> specified in device-tree.  Other options would be to a) evenly
>> distribute the GIC external interrupts across the CPU interrupt
>> vectors available to the GIC, or b) just map all GIC external
>> interrupts to a single interrupt vector.
>
> As a user I don't see why the DT author should be in charge of whether
> my UART gets higher priority than my I2C controller. That priority is
> not a fixed property of the interrupt (as the line and flags are).
>
> That said, this is a grey area. Are there any cases where this
> prioritisation is critical on existing devices?

I am not aware of any boards for which this is critical.  Malta and
SEAD-3 are development boards and do not appear to need any sort of
prioritization of GIC interrupts.  John Crispin is working on a
Mediatek board which has a GIC, but it looks like all external
interrupts are routed to a single CPU vector.  It's possible that it
could be useful on the platform I'm working on, though it's looking
more and more unlikely.

Given all that, perhaps it's better to stick with the 2-cell
(no-prioritization) binding for now and add the 3-cell binding later
if necessary.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Tue, Sep 2, 2014 at 2:33 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
> On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:
>> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
>> >> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> >> can be used to route external interrupts to individual VPEs and CPU
>> >> interrupt vectors.  It also supports a timer and software-generated
>> >> interrupts.
>> >>
>> >> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> >> ---
>> >>  Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>> >>  1 file changed, 50 insertions(+)
>> >>  create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
>> >> new file mode 100644
>> >> index 0000000..725f1ef
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> >> @@ -0,0 +1,50 @@
>> >> +MIPS Global Interrupt Controller (GIC)
>> >> +
>> >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> >> +It also supports a timer and software-generated interrupts which can be
>> >> +used as IPIs.
>> >> +
>> >> +Required properties:
>> >> +- compatible : Should be "mti,global-interrupt-controller"
>> >
>> > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
>> > there's not a patch to add it elsewhere, would you mind providing one
>> > with this series?
>>
>> Sure.  As James points out, "img" could also be used but I chose "mti"
>> since the CPU interrupt controller also uses "mti" and I believe the
>> GIC IP was developed before the acquisition by Imagination (though I'm
>> not sure if that actually matters).
>
> Using 'mti' sounds like the right choice to me given both of those
> points.
>
>> >> +- reg : Base address and length of the GIC registers.
>> >> +- interrupts : Core interrupts to which the GIC may route external interrupts.
>> >
>> > How many?
>>
>> Up to 6, one for each of the possible core hardware interrupts (i.e.
>> interrupt vectors 2 - 7).  Which ones are available to the GIC depend
>> on the system, for example Malta has an i8259 PIC hooked up to CPU
>> interrupt vector 2, so that vector should not be used by the GIC.
>>
>> > In any order?
>>
>> They can technically be in any order, but when in strictly
>> increasing/decreasing order they can be used along with the 3rd cell
>> (described below) to prioritize interrupts.
>
> Ok. Could you try to place that into the property description?
>
>> >> +- interrupt-controller : Identifies the node as an interrupt controller
>> >> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> >> +  interrupt specifier.  Should be 3.
>> >> +  - The first cell is the GIC interrupt number.
>> >> +  - The second cell encodes the interrupt flags.
>> >> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
>> >> +    flags.
>> >
>> > Are all the flags valid for this interrupt controller?
>>
>> Yes.
>
> Ok.
>
>> >> +  - The optional third cell indicates which CPU interrupt vector the GIC
>> >> +    interrupt should be routed to.  It is a 0-based index into the list of
>> >> +    GIC-to-CPU interrupts specified in the "interrupts" property described
>> >> +    above.  For example, a '2' in this cell will route the interrupt to the
>> >> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
>> >> +    be routed to the 1st core interrupt.
>> >
>> > I don't follow why this should be in the DT. Why is this necessary?
>>
>> Since the GIC can route external interrupts to any of the CPU hardware
>> interrupt vectors, it can be used to assign priorities to external
>> interrupts.  If the CPU is in vectored interrupt mode, the highest
>> numbered interrupt vector (7) has the highest priority.  An example:
>>
>> gic: interrupt-controller@1bdc0000 {
>>         ...
>>         interrupts = <3>, <4>;
>>         ...
>> };
>>
>> uart {
>>         ...
>>         interrupt-parent = <&gic>;
>>         interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
>>         ...
>> };
>>
>> i2c {
>>         ...
>>         interrupt-parent = <&gic>;
>>         interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
>>         ...
>> };
>>
>> Since the third cell for the UART is '1', it maps to CPU interrupt
>> vector 4 and thus has a higher priority than the I2C (whose third cell
>> is 0, mapping to CPU interrupt vector 3).
>>
>> Perhaps, though, this is an instance of software policy being
>> specified in device-tree.  Other options would be to a) evenly
>> distribute the GIC external interrupts across the CPU interrupt
>> vectors available to the GIC, or b) just map all GIC external
>> interrupts to a single interrupt vector.
>
> As a user I don't see why the DT author should be in charge of whether
> my UART gets higher priority than my I2C controller. That priority is
> not a fixed property of the interrupt (as the line and flags are).
>
> That said, this is a grey area. Are there any cases where this
> prioritisation is critical on existing devices?

I am not aware of any boards for which this is critical.  Malta and
SEAD-3 are development boards and do not appear to need any sort of
prioritization of GIC interrupts.  John Crispin is working on a
Mediatek board which has a GIC, but it looks like all external
interrupts are routed to a single CPU vector.  It's possible that it
could be useful on the platform I'm working on, though it's looking
more and more unlikely.

Given all that, perhaps it's better to stick with the 2-cell
(no-prioritization) binding for now and add the 3-cell binding later
if necessary.
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[David Daney]

On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
> The Global Interrupt Controller (GIC) present on certain MIPS systems
> can be used to route external interrupts to individual VPEs and CPU
> interrupt vectors.  It also supports a timer and software-generated
> interrupts.
>
> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> ---
>   Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>   1 file changed, 50 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>
> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
> new file mode 100644
> index 0000000..725f1ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> @@ -0,0 +1,50 @@
> +MIPS Global Interrupt Controller (GIC)
> +
> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> +It also supports a timer and software-generated interrupts which can be
> +used as IPIs.
> +
> +Required properties:
> +- compatible : Should be "mti,global-interrupt-controller"
> +- reg : Base address and length of the GIC registers.
> +- interrupts : Core interrupts to which the GIC may route external interrupts.

This doesn't make sense to me.  The GIC can, and does, route interrupts 
to all CPU cores in a SMP system.  How can there be a concept of only 
associating it with several interrupt lines on a single CPU in the 
system?  That is not what the GIC does, is it?  It is a Global 
interrupts controller, not local.  So specifying device tree bindings 
that don't show its Global nature seems wrong.


> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt specifier.  Should be 3.
> +  - The first cell is the GIC interrupt number.
> +  - The second cell encodes the interrupt flags.
> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
> +    flags.
> +  - The optional third cell indicates which CPU interrupt vector the GIC
> +    interrupt should be routed to.  It is a 0-based index into the list of
> +    GIC-to-CPU interrupts specified in the "interrupts" property described
> +    above.  For example, a '2' in this cell will route the interrupt to the
> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
> +    be routed to the 1st core interrupt.
> +

This seems like a really convoluted way of doing things that really goes 
against the device tree model.

The routing of interrupts through the GIC to a core interrupt is 
controlled entirely within the GIC hardware and therefore should be a 
property of the GIC itself, not all the random devices connected 
upstream to the GIC.

It also places policy about the priority of the various interrupts into 
the device tree.  Typically the device tree would contain only 
information about the topology of the hardware blocks, not arbitrary 
policy decisions that software could change and still have a perfectly 
functional system.

Therefore I would recommend removing the third cell from the interrupt 
specifier.


> +Example:
> +
> +	cpu_intc: interrupt-controller@0 {
> +		compatible = "mti,cpu-interrupt-controller";
> +
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +	};
> +
> +	gic: interrupt-controller@1bdc0000 {
> +		compatible = "mti,global-interrupt-controller";
> +		reg = <0x1bdc0000 0x20000>;
> +
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +
> +		interrupt-parent = <&cpu_intc>;
> +		interrupts = <3>, <4>;
> +	};
> +
> +	uart@18101400 {
> +		...
> +		interrupt-parent = <&gic>;
> +		interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
> +		...
> +	};
>

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[David Daney]

On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
> The Global Interrupt Controller (GIC) present on certain MIPS systems
> can be used to route external interrupts to individual VPEs and CPU
> interrupt vectors.  It also supports a timer and software-generated
> interrupts.
>
> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>   Documentation/devicetree/bindings/mips/gic.txt | 50 ++++++++++++++++++++++++++
>   1 file changed, 50 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>
> diff --git a/Documentation/devicetree/bindings/mips/gic.txt b/Documentation/devicetree/bindings/mips/gic.txt
> new file mode 100644
> index 0000000..725f1ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> @@ -0,0 +1,50 @@
> +MIPS Global Interrupt Controller (GIC)
> +
> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> +It also supports a timer and software-generated interrupts which can be
> +used as IPIs.
> +
> +Required properties:
> +- compatible : Should be "mti,global-interrupt-controller"
> +- reg : Base address and length of the GIC registers.
> +- interrupts : Core interrupts to which the GIC may route external interrupts.

This doesn't make sense to me.  The GIC can, and does, route interrupts 
to all CPU cores in a SMP system.  How can there be a concept of only 
associating it with several interrupt lines on a single CPU in the 
system?  That is not what the GIC does, is it?  It is a Global 
interrupts controller, not local.  So specifying device tree bindings 
that don't show its Global nature seems wrong.


> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt specifier.  Should be 3.
> +  - The first cell is the GIC interrupt number.
> +  - The second cell encodes the interrupt flags.
> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of valid
> +    flags.
> +  - The optional third cell indicates which CPU interrupt vector the GIC
> +    interrupt should be routed to.  It is a 0-based index into the list of
> +    GIC-to-CPU interrupts specified in the "interrupts" property described
> +    above.  For example, a '2' in this cell will route the interrupt to the
> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt will
> +    be routed to the 1st core interrupt.
> +

This seems like a really convoluted way of doing things that really goes 
against the device tree model.

The routing of interrupts through the GIC to a core interrupt is 
controlled entirely within the GIC hardware and therefore should be a 
property of the GIC itself, not all the random devices connected 
upstream to the GIC.

It also places policy about the priority of the various interrupts into 
the device tree.  Typically the device tree would contain only 
information about the topology of the hardware blocks, not arbitrary 
policy decisions that software could change and still have a perfectly 
functional system.

Therefore I would recommend removing the third cell from the interrupt 
specifier.


> +Example:
> +
> +	cpu_intc: interrupt-controller@0 {
> +		compatible = "mti,cpu-interrupt-controller";
> +
> +		interrupt-controller;
> +		#interrupt-cells = <1>;
> +	};
> +
> +	gic: interrupt-controller@1bdc0000 {
> +		compatible = "mti,global-interrupt-controller";
> +		reg = <0x1bdc0000 0x20000>;
> +
> +		interrupt-controller;
> +		#interrupt-cells = <3>;
> +
> +		interrupt-parent = <&cpu_intc>;
> +		interrupts = <3>, <4>;
> +	};
> +
> +	uart@18101400 {
> +		...
> +		interrupt-parent = <&gic>;
> +		interrupts = <24 IRQ_TYPE_LEVEL_HIGH 0>;
> +		...
> +	};
>

--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@gmail.com> wrote:
> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>
>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>> can be used to route external interrupts to individual VPEs and CPU
>> interrupt vectors.  It also supports a timer and software-generated
>> interrupts.
>>
>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>> ---
>>   Documentation/devicetree/bindings/mips/gic.txt | 50
>> ++++++++++++++++++++++++++
>>   1 file changed, 50 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>> b/Documentation/devicetree/bindings/mips/gic.txt
>> new file mode 100644
>> index 0000000..725f1ef
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>> @@ -0,0 +1,50 @@
>> +MIPS Global Interrupt Controller (GIC)
>> +
>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>> +It also supports a timer and software-generated interrupts which can be
>> +used as IPIs.
>> +
>> +Required properties:
>> +- compatible : Should be "mti,global-interrupt-controller"
>> +- reg : Base address and length of the GIC registers.
>> +- interrupts : Core interrupts to which the GIC may route external
>> interrupts.
>
>
> This doesn't make sense to me.  The GIC can, and does, route interrupts to
> all CPU cores in a SMP system.  How can there be a concept of only
> associating it with several interrupt lines on a single CPU in the system?
> That is not what the GIC does, is it?  It is a Global interrupts controller,
> not local.  So specifying device tree bindings that don't show its Global
> nature seems wrong.

While the GIC can route external interrupts to any HW interrupt vector
it may not make sense to actually use all those vectors.  For example,
the CP0 timer is usually hooked up to HW vector 5 (it could be treated
as a GIC local interrupt, though it may still be fixed to HW vector
5).  BTW, the Malta example about the i8259 I gave before was wrong -
it appears that it actually gets chained with the GIC.

What would you suggest instead?  Route all GIC interrupts to a single
vector?  Attempt to distribute them over all 6 vectors?

>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt specifier.  Should be 3.
>> +  - The first cell is the GIC interrupt number.
>> +  - The second cell encodes the interrupt flags.
>> +    See <include/dt-bindings/interrupt-controller/irq.h> for a list of
>> valid
>> +    flags.
>> +  - The optional third cell indicates which CPU interrupt vector the GIC
>> +    interrupt should be routed to.  It is a 0-based index into the list
>> of
>> +    GIC-to-CPU interrupts specified in the "interrupts" property
>> described
>> +    above.  For example, a '2' in this cell will route the interrupt to
>> the
>> +    3rd core interrupt listed in 'interrupts'.  If omitted, the interrupt
>> will
>> +    be routed to the 1st core interrupt.
>> +
>
>
> This seems like a really convoluted way of doing things that really goes
> against the device tree model.
>
> The routing of interrupts through the GIC to a core interrupt is controlled
> entirely within the GIC hardware and therefore should be a property of the
> GIC itself, not all the random devices connected upstream to the GIC.
>
> It also places policy about the priority of the various interrupts into the
> device tree.  Typically the device tree would contain only information about
> the topology of the hardware blocks, not arbitrary policy decisions that
> software could change and still have a perfectly functional system.
>
> Therefore I would recommend removing the third cell from the interrupt
> specifier.

As Mark mentioned, putting priority policy in the DT is a bit of a
gray area.  Since I don't see any need for it currently, I've decided
to drop it.

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Andrew Bresticker]

On Mon, Sep 1, 2014 at 5:08 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
> On Mon, Sep 1, 2014 at 1:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote:
>>> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
>>> >> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
>>> >> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
>>> >> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
>>> >> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
>>> >>
>>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> >>
>>> >
>>> > Why do you actually have to hardwire an IRQ base? Can't you move
>>> > to the linear irqdomain code for DT based MIPS systems yet?
>>>
>>> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
>>> still require a hard-coded IRQ base.  For boards using device-tree, I
>>> stuck with a legacy IRQ domain as it allows most of the existing GIC
>>> irqchip code to be reused.
>>
>> I see. Note that we now have irq_domain_add_simple(), which should
>> do the right think in either case: use a legacy domain when a
>> nonzero base is provided for the old boards, but use the simple
>> domain when probed from DT without an irq base.
>>
>> This makes the latter case more memory efficient (it avoids
>> allocating the irq descriptors for every possibly but unused
>> IRQ number) and helps ensure that you don't accidentally rely
>> on hardcoded IRQ numbers for the DT based machines, which would
>> be considered a bug.
>
> Ah, ok.  It looks like add_simple() is what I want then.

Actually, never mind.  To re-use the existing GIC irqchip code I want
a legacy IRQ domain.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[David Daney]

On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
> On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@gmail.com> wrote:
>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>>
>>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>>> can be used to route external interrupts to individual VPEs and CPU
>>> interrupt vectors.  It also supports a timer and software-generated
>>> interrupts.
>>>
>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>> ---
>>>    Documentation/devicetree/bindings/mips/gic.txt | 50
>>> ++++++++++++++++++++++++++
>>>    1 file changed, 50 insertions(+)
>>>    create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>>> b/Documentation/devicetree/bindings/mips/gic.txt
>>> new file mode 100644
>>> index 0000000..725f1ef
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>>> @@ -0,0 +1,50 @@
>>> +MIPS Global Interrupt Controller (GIC)
>>> +
>>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>>> +It also supports a timer and software-generated interrupts which can be
>>> +used as IPIs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "mti,global-interrupt-controller"
>>> +- reg : Base address and length of the GIC registers.
>>> +- interrupts : Core interrupts to which the GIC may route external
>>> interrupts.
>>
>>
>> This doesn't make sense to me.  The GIC can, and does, route interrupts to
>> all CPU cores in a SMP system.  How can there be a concept of only
>> associating it with several interrupt lines on a single CPU in the system?
>> That is not what the GIC does, is it?  It is a Global interrupts controller,
>> not local.  So specifying device tree bindings that don't show its Global
>> nature seems wrong.
>
> While the GIC can route external interrupts to any HW interrupt vector
> it may not make sense to actually use all those vectors.  For example,
> the CP0 timer is usually hooked up to HW vector 5 (it could be treated
> as a GIC local interrupt, though it may still be fixed to HW vector
> 5).  BTW, the Malta example about the i8259 I gave before was wrong -
> it appears that it actually gets chained with the GIC.

Your comments don't really make sense to me in the context of my 
knowledge of the GIC.

Of course all the CP0 timer and performance counter interrupts are 
per-CPU and routed directly to the corresponding CP0_Cause[IP7..IP2] 
bits.  We are don't need to give them further consideration.


Here is the scenario you should consider:

   o 16 CPU cores.
   o 1 GIC routing interrupts from external sources to the 16 CPUs.
   o 2 network controllers each with an interrupt line routed to the GIC.

Q: What would the GIC "interrupts" property look like?

Note that the GIC doesn't have a single "interrupt-parent", as it can 
route interrupts to *all* 16 CPUs.

I propose that the GIC have neither an "interrupt-parent", nor 
"interrupts".  The fact that it is an "mti,global-interrupt-controller", 
means that the software drivers for the GIC already know how to route 
interrupts, and any information the device tree could contain is redundant.

 >
 > What would you suggest instead?  Route all GIC interrupts to a single
 > vector?

Yes.  The OCTEON interrupt controllers although architecturally 
distinct, have many of the same features as the GIC, and this is what we 
do there.  You could route the IPI interrupts to IP2, and device 
interrupts to IP3, or some similar arrangement.

But the main point is that the hardware is very flexible in how the 
interrupt signals are routed.  Somehow encoding a single simple and very 
restricted topology into the device-tree doesn't seem useful to me.

It may be the case that only certain of the CP0_Cause[IP7..IP2] bits 
should  be used by the GIC in a particular system (if they are used by 
timer or profiling hardware for example).  If that is the case, then we 
would have to have some way to specify that.  But it wouldn't be done 
via the "interrupts" property.


 >  Attempt to distribute them over all 6 vectors?

No.

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[David Daney]

On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
> On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>>
>>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>>> can be used to route external interrupts to individual VPEs and CPU
>>> interrupt vectors.  It also supports a timer and software-generated
>>> interrupts.
>>>
>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>> ---
>>>    Documentation/devicetree/bindings/mips/gic.txt | 50
>>> ++++++++++++++++++++++++++
>>>    1 file changed, 50 insertions(+)
>>>    create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>>> b/Documentation/devicetree/bindings/mips/gic.txt
>>> new file mode 100644
>>> index 0000000..725f1ef
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>>> @@ -0,0 +1,50 @@
>>> +MIPS Global Interrupt Controller (GIC)
>>> +
>>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
>>> +It also supports a timer and software-generated interrupts which can be
>>> +used as IPIs.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "mti,global-interrupt-controller"
>>> +- reg : Base address and length of the GIC registers.
>>> +- interrupts : Core interrupts to which the GIC may route external
>>> interrupts.
>>
>>
>> This doesn't make sense to me.  The GIC can, and does, route interrupts to
>> all CPU cores in a SMP system.  How can there be a concept of only
>> associating it with several interrupt lines on a single CPU in the system?
>> That is not what the GIC does, is it?  It is a Global interrupts controller,
>> not local.  So specifying device tree bindings that don't show its Global
>> nature seems wrong.
>
> While the GIC can route external interrupts to any HW interrupt vector
> it may not make sense to actually use all those vectors.  For example,
> the CP0 timer is usually hooked up to HW vector 5 (it could be treated
> as a GIC local interrupt, though it may still be fixed to HW vector
> 5).  BTW, the Malta example about the i8259 I gave before was wrong -
> it appears that it actually gets chained with the GIC.

Your comments don't really make sense to me in the context of my 
knowledge of the GIC.

Of course all the CP0 timer and performance counter interrupts are 
per-CPU and routed directly to the corresponding CP0_Cause[IP7..IP2] 
bits.  We are don't need to give them further consideration.


Here is the scenario you should consider:

   o 16 CPU cores.
   o 1 GIC routing interrupts from external sources to the 16 CPUs.
   o 2 network controllers each with an interrupt line routed to the GIC.

Q: What would the GIC "interrupts" property look like?

Note that the GIC doesn't have a single "interrupt-parent", as it can 
route interrupts to *all* 16 CPUs.

I propose that the GIC have neither an "interrupt-parent", nor 
"interrupts".  The fact that it is an "mti,global-interrupt-controller", 
means that the software drivers for the GIC already know how to route 
interrupts, and any information the device tree could contain is redundant.

 >
 > What would you suggest instead?  Route all GIC interrupts to a single
 > vector?

Yes.  The OCTEON interrupt controllers although architecturally 
distinct, have many of the same features as the GIC, and this is what we 
do there.  You could route the IPI interrupts to IP2, and device 
interrupts to IP3, or some similar arrangement.

But the main point is that the hardware is very flexible in how the 
interrupt signals are routed.  Somehow encoding a single simple and very 
restricted topology into the device-tree doesn't seem useful to me.

It may be the case that only certain of the CP0_Cause[IP7..IP2] bits 
should  be used by the GIC in a particular system (if they are used by 
timer or profiling hardware for example).  If that is the case, then we 
would have to have some way to specify that.  But it wouldn't be done 
via the "interrupts" property.


 >  Attempt to distribute them over all 6 vectors?

No.
--
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

Re: [PATCH 04/12] MIPS: GIC: Move MIPS_GIC_IRQ_BASE into platform irq.h

[Arnd Bergmann]

On Tuesday 02 September 2014 15:22:31 Andrew Bresticker wrote:
> On Mon, Sep 1, 2014 at 5:08 PM, Andrew Bresticker <abrestic@chromium.org> wrote:
> > On Mon, Sep 1, 2014 at 1:34 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Sunday 31 August 2014 11:54:04 Andrew Bresticker wrote:
> >>> On Sat, Aug 30, 2014 at 12:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >>> > On Friday 29 August 2014 15:14:31 Andrew Bresticker wrote:
> >>> >> Define a generic MIPS_GIC_IRQ_BASE which is suitable for Malta and
> >>> >> the upcoming Danube board in <mach-generic/irq.h>.  Since Sead-3 is
> >>> >> different and uses a MIPS_GIC_IRQ_BASE equal to the CPU IRQ base (0),
> >>> >> define its MIPS_GIC_IRQ_BASE in <mach-sead3/irq.h>.
> >>> >>
> >>> >> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
> >>> >>
> >>> >
> >>> > Why do you actually have to hardwire an IRQ base? Can't you move
> >>> > to the linear irqdomain code for DT based MIPS systems yet?
> >>>
> >>> Neither Malta nor SEAD-3 use device-tree for interrupts yet, so they
> >>> still require a hard-coded IRQ base.  For boards using device-tree, I
> >>> stuck with a legacy IRQ domain as it allows most of the existing GIC
> >>> irqchip code to be reused.
> >>
> >> I see. Note that we now have irq_domain_add_simple(), which should
> >> do the right think in either case: use a legacy domain when a
> >> nonzero base is provided for the old boards, but use the simple
> >> domain when probed from DT without an irq base.
> >>
> >> This makes the latter case more memory efficient (it avoids
> >> allocating the irq descriptors for every possibly but unused
> >> IRQ number) and helps ensure that you don't accidentally rely
> >> on hardcoded IRQ numbers for the DT based machines, which would
> >> be considered a bug.
> >
> > Ah, ok.  It looks like add_simple() is what I want then.
> 
> Actually, never mind.  To re-use the existing GIC irqchip code I want
> a legacy IRQ domain.

It shouldn't be hard to change the existing code to use irq domain
accessors. The main part is probably just to replace 'd->irq -
gic_irq_base' with 'd->hwirq', in case you make up your mind about
it again.

	Arnd

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Tue, Sep 2, 2014 at 5:50 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
>>
>> On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm@gmail.com>
>> wrote:
>>>
>>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>>>
>>>>
>>>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>>>> can be used to route external interrupts to individual VPEs and CPU
>>>> interrupt vectors.  It also supports a timer and software-generated
>>>> interrupts.
>>>>
>>>> Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
>>>> ---
>>>>    Documentation/devicetree/bindings/mips/gic.txt | 50
>>>> ++++++++++++++++++++++++++
>>>>    1 file changed, 50 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>>>> b/Documentation/devicetree/bindings/mips/gic.txt
>>>> new file mode 100644
>>>> index 0000000..725f1ef
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>>>> @@ -0,0 +1,50 @@
>>>> +MIPS Global Interrupt Controller (GIC)
>>>> +
>>>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ
>>>> pins.
>>>> +It also supports a timer and software-generated interrupts which can be
>>>> +used as IPIs.
>>>> +
>>>> +Required properties:
>>>> +- compatible : Should be "mti,global-interrupt-controller"
>>>> +- reg : Base address and length of the GIC registers.
>>>> +- interrupts : Core interrupts to which the GIC may route external
>>>> interrupts.
>>>
>>>
>>>
>>> This doesn't make sense to me.  The GIC can, and does, route interrupts
>>> to
>>> all CPU cores in a SMP system.  How can there be a concept of only
>>> associating it with several interrupt lines on a single CPU in the
>>> system?
>>> That is not what the GIC does, is it?  It is a Global interrupts
>>> controller,
>>> not local.  So specifying device tree bindings that don't show its Global
>>> nature seems wrong.
>>
>>
>> While the GIC can route external interrupts to any HW interrupt vector
>> it may not make sense to actually use all those vectors.  For example,
>> the CP0 timer is usually hooked up to HW vector 5 (it could be treated
>> as a GIC local interrupt, though it may still be fixed to HW vector
>> 5).  BTW, the Malta example about the i8259 I gave before was wrong -
>> it appears that it actually gets chained with the GIC.
>
>
> Your comments don't really make sense to me in the context of my knowledge
> of the GIC.
>
> Of course all the CP0 timer and performance counter interrupts are per-CPU
> and routed directly to the corresponding CP0_Cause[IP7..IP2] bits.  We are
> don't need to give them further consideration.
>
>
> Here is the scenario you should consider:
>
>   o 16 CPU cores.
>   o 1 GIC routing interrupts from external sources to the 16 CPUs.
>   o 2 network controllers each with an interrupt line routed to the GIC.
>
> Q: What would the GIC "interrupts" property look like?
>
> Note that the GIC doesn't have a single "interrupt-parent", as it can route
> interrupts to *all* 16 CPUs.
>
> I propose that the GIC have neither an "interrupt-parent", nor "interrupts".
> The fact that it is an "mti,global-interrupt-controller", means that the
> software drivers for the GIC already know how to route interrupts, and any
> information the device tree could contain is redundant.

Ok, I misunderstood your opposition to the binding.

My intention for the "interrupt-parent" and "interrupts" property of
the GIC was to express that GIC interrupts are routed to the CPU
interrupt vectors and that a certain set of these vectors are
available for use by the GIC.  I would agree that these are mostly
redundant (obviously the GIC routes interrupts to CPU interrupt
vecotrs) and that it is not the most accurate description of the
GIC-CPU relationship (the CPU interrupt controller are per-CPU, not
global, and the GIC can route interrupts to any of them), though I'm
not sure that there's a better way of describing it in DT.

So that leaves us with something like this:

interrupt-controller@1bdc0000 {
        compatible = "mti,global-interrupt-controller";

        interrupt-controller;
        #interrupt-cells = <2>;

        available-cpu-vectors = <2>, <3>, ...
};

DT folks, thoughts?

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[Andrew Bresticker]

On Tue, Sep 2, 2014 at 5:50 PM, David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 09/02/2014 12:36 PM, Andrew Bresticker wrote:
>>
>> On Tue, Sep 2, 2014 at 10:27 AM, David Daney <ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> wrote:
>>>
>>> On 08/29/2014 03:14 PM, Andrew Bresticker wrote:
>>>>
>>>>
>>>> The Global Interrupt Controller (GIC) present on certain MIPS systems
>>>> can be used to route external interrupts to individual VPEs and CPU
>>>> interrupt vectors.  It also supports a timer and software-generated
>>>> interrupts.
>>>>
>>>> Signed-off-by: Andrew Bresticker <abrestic-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>>> ---
>>>>    Documentation/devicetree/bindings/mips/gic.txt | 50
>>>> ++++++++++++++++++++++++++
>>>>    1 file changed, 50 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
>>>> b/Documentation/devicetree/bindings/mips/gic.txt
>>>> new file mode 100644
>>>> index 0000000..725f1ef
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mips/gic.txt
>>>> @@ -0,0 +1,50 @@
>>>> +MIPS Global Interrupt Controller (GIC)
>>>> +
>>>> +The MIPS GIC routes external interrupts to individual VPEs and IRQ
>>>> pins.
>>>> +It also supports a timer and software-generated interrupts which can be
>>>> +used as IPIs.
>>>> +
>>>> +Required properties:
>>>> +- compatible : Should be "mti,global-interrupt-controller"
>>>> +- reg : Base address and length of the GIC registers.
>>>> +- interrupts : Core interrupts to which the GIC may route external
>>>> interrupts.
>>>
>>>
>>>
>>> This doesn't make sense to me.  The GIC can, and does, route interrupts
>>> to
>>> all CPU cores in a SMP system.  How can there be a concept of only
>>> associating it with several interrupt lines on a single CPU in the
>>> system?
>>> That is not what the GIC does, is it?  It is a Global interrupts
>>> controller,
>>> not local.  So specifying device tree bindings that don't show its Global
>>> nature seems wrong.
>>
>>
>> While the GIC can route external interrupts to any HW interrupt vector
>> it may not make sense to actually use all those vectors.  For example,
>> the CP0 timer is usually hooked up to HW vector 5 (it could be treated
>> as a GIC local interrupt, though it may still be fixed to HW vector
>> 5).  BTW, the Malta example about the i8259 I gave before was wrong -
>> it appears that it actually gets chained with the GIC.
>
>
> Your comments don't really make sense to me in the context of my knowledge
> of the GIC.
>
> Of course all the CP0 timer and performance counter interrupts are per-CPU
> and routed directly to the corresponding CP0_Cause[IP7..IP2] bits.  We are
> don't need to give them further consideration.
>
>
> Here is the scenario you should consider:
>
>   o 16 CPU cores.
>   o 1 GIC routing interrupts from external sources to the 16 CPUs.
>   o 2 network controllers each with an interrupt line routed to the GIC.
>
> Q: What would the GIC "interrupts" property look like?
>
> Note that the GIC doesn't have a single "interrupt-parent", as it can route
> interrupts to *all* 16 CPUs.
>
> I propose that the GIC have neither an "interrupt-parent", nor "interrupts".
> The fact that it is an "mti,global-interrupt-controller", means that the
> software drivers for the GIC already know how to route interrupts, and any
> information the device tree could contain is redundant.

Ok, I misunderstood your opposition to the binding.

My intention for the "interrupt-parent" and "interrupts" property of
the GIC was to express that GIC interrupts are routed to the CPU
interrupt vectors and that a certain set of these vectors are
available for use by the GIC.  I would agree that these are mostly
redundant (obviously the GIC routes interrupts to CPU interrupt
vecotrs) and that it is not the most accurate description of the
GIC-CPU relationship (the CPU interrupt controller are per-CPU, not
global, and the GIC can route interrupts to any of them), though I'm
not sure that there's a better way of describing it in DT.

So that leaves us with something like this:

interrupt-controller@1bdc0000 {
        compatible = "mti,global-interrupt-controller";

        interrupt-controller;
        #interrupt-cells = <2>;

        available-cpu-vectors = <2>, <3>, ...
};

DT folks, thoughts?
--
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

Re: [PATCH 03/12] of: Add binding document for MIPS GIC

[David Daney]

On 09/03/2014 04:53 PM, Andrew Bresticker wrote:
> On Tue, Sep 2, 2014 at 5:50 PM, David Daney <ddaney.cavm@gmail.com> wrote:
[...]
>>
>> Your comments don't really make sense to me in the context of my knowledge
>> of the GIC.
>>
>> Of course all the CP0 timer and performance counter interrupts are per-CPU
>> and routed directly to the corresponding CP0_Cause[IP7..IP2] bits.  We are
>> don't need to give them further consideration.
>>
>>
>> Here is the scenario you should consider:
>>
>>    o 16 CPU cores.
>>    o 1 GIC routing interrupts from external sources to the 16 CPUs.
>>    o 2 network controllers each with an interrupt line routed to the GIC.
>>
>> Q: What would the GIC "interrupts" property look like?
>>
>> Note that the GIC doesn't have a single "interrupt-parent", as it can route
>> interrupts to *all* 16 CPUs.
>>
>> I propose that the GIC have neither an "interrupt-parent", nor "interrupts".
>> The fact that it is an "mti,global-interrupt-controller", means that the
>> software drivers for the GIC already know how to route interrupts, and any
>> information the device tree could contain is redundant.
>
> Ok, I misunderstood your opposition to the binding.
>
> My intention for the "interrupt-parent" and "interrupts" property of
> the GIC was to express that GIC interrupts are routed to the CPU
> interrupt vectors and that a certain set of these vectors are
> available for use by the GIC.  I would agree that these are mostly
> redundant (obviously the GIC routes interrupts to CPU interrupt
> vecotrs) and that it is not the most accurate description of the
> GIC-CPU relationship (the CPU interrupt controller are per-CPU, not
> global, and the GIC can route interrupts to any of them), though I'm
> not sure that there's a better way of describing it in DT.
>
> So that leaves us with something like this:
>
> interrupt-controller@1bdc0000 {
>          compatible = "mti,global-interrupt-controller";
>
>          interrupt-controller;
>          #interrupt-cells = <2>;
>
>          available-cpu-vectors = <2>, <3>, ...


Exactly what I had in mind, except for the missing "reg" property.

This gives software the information it needs, but doesn't impose any policy.

I will defer to others on the exact name the "available-cpu-vectors" 
should have.




> };
>
> DT folks, thoughts?
>
>