[PATCH 0/5] GIC OF bindings

[PATCH 0/5] GIC OF bindings

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

This series introduces of_irq_init to scan the device tree for interrupt
controller nodes and call their init functions in proper order. The GIC
init function is then called from this function. The platform code then
looks something like this:

const static struct of_device_id irq_match[] = {
	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
	{}
};

static void __init highbank_init_irq(void)
{
	of_irq_init(irq_match);
}

The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
and suggested by Grant.

I dropped the public intc_desc struct. The the interrupt controller's node
and the interrupt parent's node are passed in directly to the controller's
init function. The linux irq assignment is now done dynamically using
irq_alloc_descs.

The first 2 patches are minor fixes to irqdomains.

Rob

Rob Herring (5):
  irq: add declaration of irq_domain_simple_ops to irqdomain.h
  irq: fix existing domain check in irq_domain_add
  of/irq: introduce of_irq_init
  ARM: gic: allow irq_start to be 0
  ARM: gic: add OF based initialization

 Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++
 arch/arm/common/gic.c                         |   57 +++++++++++++--
 arch/arm/include/asm/hardware/gic.h           |   10 +++
 drivers/of/irq.c                              |   96 +++++++++++++++++++++++++
 include/linux/irqdomain.h                     |    1 +
 include/linux/of_irq.h                        |    1 +
 kernel/irq/irqdomain.c                        |    2 +-
 7 files changed, 214 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

-- 
1.7.5.4

[PATCH 0/5] GIC OF bindings

[Rob Herring]

From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

This series introduces of_irq_init to scan the device tree for interrupt
controller nodes and call their init functions in proper order. The GIC
init function is then called from this function. The platform code then
looks something like this:

const static struct of_device_id irq_match[] = {
	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
	{}
};

static void __init highbank_init_irq(void)
{
	of_irq_init(irq_match);
}

The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
and suggested by Grant.

I dropped the public intc_desc struct. The the interrupt controller's node
and the interrupt parent's node are passed in directly to the controller's
init function. The linux irq assignment is now done dynamically using
irq_alloc_descs.

The first 2 patches are minor fixes to irqdomains.

Rob

Rob Herring (5):
  irq: add declaration of irq_domain_simple_ops to irqdomain.h
  irq: fix existing domain check in irq_domain_add
  of/irq: introduce of_irq_init
  ARM: gic: allow irq_start to be 0
  ARM: gic: add OF based initialization

 Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++
 arch/arm/common/gic.c                         |   57 +++++++++++++--
 arch/arm/include/asm/hardware/gic.h           |   10 +++
 drivers/of/irq.c                              |   96 +++++++++++++++++++++++++
 include/linux/irqdomain.h                     |    1 +
 include/linux/of_irq.h                        |    1 +
 kernel/irq/irqdomain.c                        |    2 +-
 7 files changed, 214 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

-- 
1.7.5.4

[PATCH 0/5] GIC OF bindings

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

This series introduces of_irq_init to scan the device tree for interrupt
controller nodes and call their init functions in proper order. The GIC
init function is then called from this function. The platform code then
looks something like this:

const static struct of_device_id irq_match[] = {
	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
	{}
};

static void __init highbank_init_irq(void)
{
	of_irq_init(irq_match);
}

The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
and suggested by Grant.

I dropped the public intc_desc struct. The the interrupt controller's node
and the interrupt parent's node are passed in directly to the controller's
init function. The linux irq assignment is now done dynamically using
irq_alloc_descs.

The first 2 patches are minor fixes to irqdomains.

Rob

Rob Herring (5):
  irq: add declaration of irq_domain_simple_ops to irqdomain.h
  irq: fix existing domain check in irq_domain_add
  of/irq: introduce of_irq_init
  ARM: gic: allow irq_start to be 0
  ARM: gic: add OF based initialization

 Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++
 arch/arm/common/gic.c                         |   57 +++++++++++++--
 arch/arm/include/asm/hardware/gic.h           |   10 +++
 drivers/of/irq.c                              |   96 +++++++++++++++++++++++++
 include/linux/irqdomain.h                     |    1 +
 include/linux/of_irq.h                        |    1 +
 kernel/irq/irqdomain.c                        |    2 +-
 7 files changed, 214 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

-- 
1.7.5.4

[PATCH 1/5] irq: add declaration of irq_domain_simple_ops to irqdomain.h

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

irq_domain_simple_ops is exported, but is not declared in irqdomain.h, so
add it.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/irqdomain.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index e807ad6..3ad553e 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -80,6 +80,7 @@ extern void irq_domain_del(struct irq_domain *domain);
 #endif /* CONFIG_IRQ_DOMAIN */
 
 #if defined(CONFIG_IRQ_DOMAIN) && defined(CONFIG_OF_IRQ)
+extern struct irq_domain_ops irq_domain_simple_ops;
 extern void irq_domain_add_simple(struct device_node *controller, int irq_base);
 extern void irq_domain_generate_simple(const struct of_device_id *match,
 					u64 phys_base, unsigned int irq_start);
-- 
1.7.5.4

[PATCH 1/5] irq: add declaration of irq_domain_simple_ops to irqdomain.h

[Rob Herring]

From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

irq_domain_simple_ops is exported, but is not declared in irqdomain.h, so
add it.

Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
---
 include/linux/irqdomain.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index e807ad6..3ad553e 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -80,6 +80,7 @@ extern void irq_domain_del(struct irq_domain *domain);
 #endif /* CONFIG_IRQ_DOMAIN */
 
 #if defined(CONFIG_IRQ_DOMAIN) && defined(CONFIG_OF_IRQ)
+extern struct irq_domain_ops irq_domain_simple_ops;
 extern void irq_domain_add_simple(struct device_node *controller, int irq_base);
 extern void irq_domain_generate_simple(const struct of_device_id *match,
 					u64 phys_base, unsigned int irq_start);
-- 
1.7.5.4

[PATCH 1/5] irq: add declaration of irq_domain_simple_ops to irqdomain.h

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

irq_domain_simple_ops is exported, but is not declared in irqdomain.h, so
add it.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/irqdomain.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index e807ad6..3ad553e 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -80,6 +80,7 @@ extern void irq_domain_del(struct irq_domain *domain);
 #endif /* CONFIG_IRQ_DOMAIN */
 
 #if defined(CONFIG_IRQ_DOMAIN) && defined(CONFIG_OF_IRQ)
+extern struct irq_domain_ops irq_domain_simple_ops;
 extern void irq_domain_add_simple(struct device_node *controller, int irq_base);
 extern void irq_domain_generate_simple(const struct of_device_id *match,
 					u64 phys_base, unsigned int irq_start);
-- 
1.7.5.4

[PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

irq_data will normally exist, so the domain was prevented from being set.
The simple domain code did not hit this as nr_irq is always 0.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/irq/irqdomain.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index d5828da..84f4110 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
 	 */
 	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
 		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
-		if (d || d->domain) {
+		if (d && d->domain) {
 			/* things are broken; just report, don't clean up */
 			WARN(1, "error: irq_desc already assigned to a domain");
 			return;
-- 
1.7.5.4

[PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

irq_data will normally exist, so the domain was prevented from being set.
The simple domain code did not hit this as nr_irq is always 0.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
 kernel/irq/irqdomain.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index d5828da..84f4110 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
 	 */
 	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
 		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
-		if (d || d->domain) {
+		if (d && d->domain) {
 			/* things are broken; just report, don't clean up */
 			WARN(1, "error: irq_desc already assigned to a domain");
 			return;
-- 
1.7.5.4

[PATCH 3/5] of/irq: introduce of_irq_init

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

of_irq_init will scan the devicetree for matching interrupt controller
nodes. Then it calls an initialization function for each found controller
in the proper order with parent nodes initialized before child nodes.

Based on initial pseudo code from Grant Likely.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
 drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_irq.h |    1 +
 2 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9f689f1..a0cd7e8 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -19,10 +19,13 @@
  */
 
 #include <linux/errno.h>
+#include <linux/list.h>
+#include <linux/list_sort.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/string.h>
+#include <linux/slab.h>
 
 /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
 #ifndef NO_IRQ
@@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
 
 	return i;
 }
+
+struct intc_desc {
+	struct list_head	list;
+	struct device_node	*dev;
+	struct device_node	*parent;
+};
+
+typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
+
+static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
+				    struct list_head *b)
+{
+	const struct intc_desc *da = list_entry(a, typeof(*da), list);
+	const struct intc_desc *db = list_entry(b, typeof(*db), list);
+
+	/* same parent, so order doesn't matter */
+	if (da->parent == db->parent)
+		return 0;
+
+	/* NULL parent comes first */
+	if (!da->parent && db->parent)
+		return -1;
+	if (!db->parent && da->parent)
+		return 1;
+
+	/* parent node must be before child node */
+	if (da->dev == db->parent)
+		return -1;
+	if (db->dev == da->parent)
+		return 1;
+
+	return 0;
+}
+
+/**
+ * of_irq_init - Scan the device tree for matching interrupt controllers and
+ * call their initialization functions in order with parents first.
+ * @matches: 0 terminated array of nodes to match and initialization function
+ * to call on match
+ */
+void __init of_irq_init(const struct of_device_id *matches)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+	struct intc_desc *desc;
+	struct intc_desc *temp_desc;
+	struct list_head intc_desc_list;
+
+	INIT_LIST_HEAD(&intc_desc_list);
+
+	for_each_matching_node(np, matches) {
+		if (!of_find_property(np, "interrupt-controller", NULL))
+			continue;
+		/* Here, we allocate and populate an intc_desc with the node
+		* pointer, interrupt-parent device_node etc. */
+		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+		if (!desc) {
+			WARN_ON(1);
+			goto err;
+		}
+		desc->dev = np;
+		desc->parent = of_irq_find_parent(np);
+		list_add(&desc->list, &intc_desc_list);
+	}
+	if (list_empty(&intc_desc_list))
+		return;
+
+	/*
+	 * The root irq controller is the one without an interrupt-parent.
+	 * That one goes first, followed by the controllers that reference it,
+	 * followed by the ones that reference the 2nd level controllers, etc
+	 */
+	list_sort(NULL, &intc_desc_list, irq_cmp_intc_desc);
+
+	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+		match = of_match_node(matches, desc->dev);
+		if (match && match->data) {
+			irq_init_cb_t irq_init_cb = match->data;
+			pr_debug("of_irq_init: init %s @ %p, parent %p\n",
+				 match->compatible, desc->dev, desc->parent);
+			irq_init_cb(desc->dev, desc->parent);
+		}
+		list_del(&desc->list);
+		kfree(desc);
+	}
+	return;
+
+err:
+	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+		list_del(&desc->list);
+		kfree(desc);
+	}
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index cd2e61c..032d76c 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
 		struct resource *res, int nr_irqs);
 extern struct device_node *of_irq_find_parent(struct device_node *child);
 
+extern void of_irq_init(const struct of_device_id *matches);
 
 #endif /* CONFIG_OF_IRQ */
 #endif /* CONFIG_OF */
-- 
1.7.5.4

[PATCH 3/5] of/irq: introduce of_irq_init

[Rob Herring]

From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

of_irq_init will scan the devicetree for matching interrupt controller
nodes. Then it calls an initialization function for each found controller
in the proper order with parent nodes initialized before child nodes.

Based on initial pseudo code from Grant Likely.

Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---
 drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_irq.h |    1 +
 2 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9f689f1..a0cd7e8 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -19,10 +19,13 @@
  */
 
 #include <linux/errno.h>
+#include <linux/list.h>
+#include <linux/list_sort.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/string.h>
+#include <linux/slab.h>
 
 /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
 #ifndef NO_IRQ
@@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
 
 	return i;
 }
+
+struct intc_desc {
+	struct list_head	list;
+	struct device_node	*dev;
+	struct device_node	*parent;
+};
+
+typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
+
+static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
+				    struct list_head *b)
+{
+	const struct intc_desc *da = list_entry(a, typeof(*da), list);
+	const struct intc_desc *db = list_entry(b, typeof(*db), list);
+
+	/* same parent, so order doesn't matter */
+	if (da->parent == db->parent)
+		return 0;
+
+	/* NULL parent comes first */
+	if (!da->parent && db->parent)
+		return -1;
+	if (!db->parent && da->parent)
+		return 1;
+
+	/* parent node must be before child node */
+	if (da->dev == db->parent)
+		return -1;
+	if (db->dev == da->parent)
+		return 1;
+
+	return 0;
+}
+
+/**
+ * of_irq_init - Scan the device tree for matching interrupt controllers and
+ * call their initialization functions in order with parents first.
+ * @matches: 0 terminated array of nodes to match and initialization function
+ * to call on match
+ */
+void __init of_irq_init(const struct of_device_id *matches)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+	struct intc_desc *desc;
+	struct intc_desc *temp_desc;
+	struct list_head intc_desc_list;
+
+	INIT_LIST_HEAD(&intc_desc_list);
+
+	for_each_matching_node(np, matches) {
+		if (!of_find_property(np, "interrupt-controller", NULL))
+			continue;
+		/* Here, we allocate and populate an intc_desc with the node
+		* pointer, interrupt-parent device_node etc. */
+		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+		if (!desc) {
+			WARN_ON(1);
+			goto err;
+		}
+		desc->dev = np;
+		desc->parent = of_irq_find_parent(np);
+		list_add(&desc->list, &intc_desc_list);
+	}
+	if (list_empty(&intc_desc_list))
+		return;
+
+	/*
+	 * The root irq controller is the one without an interrupt-parent.
+	 * That one goes first, followed by the controllers that reference it,
+	 * followed by the ones that reference the 2nd level controllers, etc
+	 */
+	list_sort(NULL, &intc_desc_list, irq_cmp_intc_desc);
+
+	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+		match = of_match_node(matches, desc->dev);
+		if (match && match->data) {
+			irq_init_cb_t irq_init_cb = match->data;
+			pr_debug("of_irq_init: init %s @ %p, parent %p\n",
+				 match->compatible, desc->dev, desc->parent);
+			irq_init_cb(desc->dev, desc->parent);
+		}
+		list_del(&desc->list);
+		kfree(desc);
+	}
+	return;
+
+err:
+	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+		list_del(&desc->list);
+		kfree(desc);
+	}
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index cd2e61c..032d76c 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
 		struct resource *res, int nr_irqs);
 extern struct device_node *of_irq_find_parent(struct device_node *child);
 
+extern void of_irq_init(const struct of_device_id *matches);
 
 #endif /* CONFIG_OF_IRQ */
 #endif /* CONFIG_OF */
-- 
1.7.5.4

[PATCH 3/5] of/irq: introduce of_irq_init

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

of_irq_init will scan the devicetree for matching interrupt controller
nodes. Then it calls an initialization function for each found controller
in the proper order with parent nodes initialized before child nodes.

Based on initial pseudo code from Grant Likely.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
 drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_irq.h |    1 +
 2 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 9f689f1..a0cd7e8 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -19,10 +19,13 @@
  */
 
 #include <linux/errno.h>
+#include <linux/list.h>
+#include <linux/list_sort.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
 #include <linux/string.h>
+#include <linux/slab.h>
 
 /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
 #ifndef NO_IRQ
@@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
 
 	return i;
 }
+
+struct intc_desc {
+	struct list_head	list;
+	struct device_node	*dev;
+	struct device_node	*parent;
+};
+
+typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
+
+static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
+				    struct list_head *b)
+{
+	const struct intc_desc *da = list_entry(a, typeof(*da), list);
+	const struct intc_desc *db = list_entry(b, typeof(*db), list);
+
+	/* same parent, so order doesn't matter */
+	if (da->parent == db->parent)
+		return 0;
+
+	/* NULL parent comes first */
+	if (!da->parent && db->parent)
+		return -1;
+	if (!db->parent && da->parent)
+		return 1;
+
+	/* parent node must be before child node */
+	if (da->dev == db->parent)
+		return -1;
+	if (db->dev == da->parent)
+		return 1;
+
+	return 0;
+}
+
+/**
+ * of_irq_init - Scan the device tree for matching interrupt controllers and
+ * call their initialization functions in order with parents first.
+ * @matches: 0 terminated array of nodes to match and initialization function
+ * to call on match
+ */
+void __init of_irq_init(const struct of_device_id *matches)
+{
+	struct device_node *np;
+	const struct of_device_id *match;
+	struct intc_desc *desc;
+	struct intc_desc *temp_desc;
+	struct list_head intc_desc_list;
+
+	INIT_LIST_HEAD(&intc_desc_list);
+
+	for_each_matching_node(np, matches) {
+		if (!of_find_property(np, "interrupt-controller", NULL))
+			continue;
+		/* Here, we allocate and populate an intc_desc with the node
+		* pointer, interrupt-parent device_node etc. */
+		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+		if (!desc) {
+			WARN_ON(1);
+			goto err;
+		}
+		desc->dev = np;
+		desc->parent = of_irq_find_parent(np);
+		list_add(&desc->list, &intc_desc_list);
+	}
+	if (list_empty(&intc_desc_list))
+		return;
+
+	/*
+	 * The root irq controller is the one without an interrupt-parent.
+	 * That one goes first, followed by the controllers that reference it,
+	 * followed by the ones that reference the 2nd level controllers, etc
+	 */
+	list_sort(NULL, &intc_desc_list, irq_cmp_intc_desc);
+
+	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+		match = of_match_node(matches, desc->dev);
+		if (match && match->data) {
+			irq_init_cb_t irq_init_cb = match->data;
+			pr_debug("of_irq_init: init %s @ %p, parent %p\n",
+				 match->compatible, desc->dev, desc->parent);
+			irq_init_cb(desc->dev, desc->parent);
+		}
+		list_del(&desc->list);
+		kfree(desc);
+	}
+	return;
+
+err:
+	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
+		list_del(&desc->list);
+		kfree(desc);
+	}
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index cd2e61c..032d76c 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
 		struct resource *res, int nr_irqs);
 extern struct device_node *of_irq_find_parent(struct device_node *child);
 
+extern void of_irq_init(const struct of_device_id *matches);
 
 #endif /* CONFIG_OF_IRQ */
 #endif /* CONFIG_OF */
-- 
1.7.5.4

[PATCH 4/5] ARM: gic: allow irq_start to be 0

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

There's really no need to set irq_start per platform for the primary gic.
The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
setup doesn't really matter. So allow irq_start to be set to 0 to match
the linux irq numbering.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 arch/arm/common/gic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 666b278..d1ccc72 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -359,7 +359,7 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
 	gic = &gic_data[gic_nr];
 	gic->dist_base = dist_base;
 	gic->cpu_base = cpu_base;
-	gic->irq_offset = (irq_start - 1) & ~31;
+	gic->irq_offset = irq_start ? (irq_start - 1) & ~31 : 0;
 
 	if (gic_nr == 0)
 		gic_cpu_base_addr = cpu_base;
-- 
1.7.5.4

[PATCH 4/5] ARM: gic: allow irq_start to be 0

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

There's really no need to set irq_start per platform for the primary gic.
The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
setup doesn't really matter. So allow irq_start to be set to 0 to match
the linux irq numbering.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 arch/arm/common/gic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 666b278..d1ccc72 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -359,7 +359,7 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
 	gic = &gic_data[gic_nr];
 	gic->dist_base = dist_base;
 	gic->cpu_base = cpu_base;
-	gic->irq_offset = (irq_start - 1) & ~31;
+	gic->irq_offset = irq_start ? (irq_start - 1) & ~31 : 0;
 
 	if (gic_nr == 0)
 		gic_cpu_base_addr = cpu_base;
-- 
1.7.5.4

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

This adds gic initialization using device tree data. The initialization
functions are intended to be called by a generic OF interrupt
controller parsing function once the right pieces are in place.

PPIs are handled using 3rd cell of interrupts properties to specify the cpu
mask the PPI is assigned to.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
 arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
 arch/arm/include/asm/hardware/gic.h           |   10 +++++
 3 files changed, 114 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
new file mode 100644
index 0000000..6c513de
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -0,0 +1,53 @@
+* ARM Generic Interrupt Controller
+
+ARM SMP cores are often associated with a GIC, providing per processor
+interrupts (PPI), shared processor interrupts (SPI) and software
+generated interrupts (SGI).
+
+Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
+Secondary GICs are cascaded into the upward interrupt controller and do not
+have PPIs or SGIs.
+
+Main node required properties:
+
+- compatible : should be one of:
+	"arm,cortex-a9-gic"
+	"arm,arm11mp-gic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source.  The type shall be a <u32> and the value shall be 3.
+
+  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
+  for PPIs.
+
+  The 2nd cell is the level-sense information, encoded as follows:
+                    1 = low-to-high edge triggered
+                    2 = high-to-low edge triggered
+                    4 = active high level-sensitive
+                    8 = active low level-sensitive
+
+  Only values of 1 and 4 are valid for GIC 1.0 spec.
+
+  The 3rd cell contains the mask of the cpu number for the interrupt source.
+  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
+  be 0 for PPIs.
+
+- reg : Specifies base physical address(s) and size of the GIC registers. The
+  first 2 values are the GIC distributor register base and size. The 2nd 2
+  values are the GIC cpu interface register base and size.
+
+Optional
+- interrupts	: Interrupt source of the parent interrupt controller. Only
+  present on secondary GICs.
+
+Example:
+
+	intc: interrupt-controller@fff11000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		interrupt-controller;
+		reg = <0xfff11000 0x1000>,
+		      <0xfff10100 0x100>;
+	};
+
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index d1ccc72..14de380 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -28,6 +28,10 @@
 #include <linux/smp.h>
 #include <linux/cpumask.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
 
 #include <asm/irq.h>
 #include <asm/mach/irq.h>
@@ -255,6 +259,15 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
 	irq_set_chained_handler(irq, gic_handle_cascade_irq);
 }
 
+static int gic_irq_count(void __iomem *dist_base)
+{
+	int gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
+	gic_irqs = (gic_irqs + 1) * 32;
+	if (gic_irqs > 1020)
+		gic_irqs = 1020;
+	return gic_irqs;
+}
+
 static void __init gic_dist_init(struct gic_chip_data *gic,
 	unsigned int irq_start)
 {
@@ -277,10 +290,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
 	 * Find out how many interrupts are supported.
 	 * The GIC only supports up to 1020 interrupt sources.
 	 */
-	gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
-	gic_irqs = (gic_irqs + 1) * 32;
-	if (gic_irqs > 1020)
-		gic_irqs = 1020;
+	gic_irqs = gic_irq_count(base);
 
 	/*
 	 * Set all global interrupts to be level triggered, active low.
@@ -405,3 +415,40 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 	writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
 }
 #endif
+
+#ifdef CONFIG_OF
+static int gic_cnt __initdata = 0;
+
+extern struct irq_domain_ops irq_domain_simple_ops;
+
+void __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+	void __iomem *cpu_base;
+	void __iomem *dist_base;
+	int irq;
+	struct irq_domain *domain = &gic_data[gic_cnt].domain;
+
+	if (WARN_ON(!node))
+		return;
+
+	dist_base = of_iomap(node, 0);
+	WARN(!dist_base, "unable to map gic dist registers\n");
+
+	cpu_base = of_iomap(node, 1);
+	WARN(!cpu_base, "unable to map gic cpu registers\n");
+
+	domain->nr_irq = gic_irq_count(dist_base);
+	domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
+	domain->of_node = of_node_get(node);
+	domain->ops = &irq_domain_simple_ops;
+	irq_domain_add(domain);
+
+	gic_init(gic_cnt, domain->irq_base, dist_base, cpu_base);
+
+	if (parent) {
+		irq = irq_of_parse_and_map(node, 0);
+		gic_cascade_irq(gic_cnt, irq);
+	}
+	gic_cnt++;
+}
+#endif
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 435d3f8..ea1ca08 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -33,10 +33,19 @@
 #define GIC_DIST_SOFTINT		0xf00
 
 #ifndef __ASSEMBLY__
+#include <linux/irqdomain.h>
+
 extern void __iomem *gic_cpu_base_addr;
 extern struct irq_chip gic_arch_extn;
 
 void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+#ifdef CONFIG_OF
+void gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline void gic_of_init(struct device_node *node,
+			       struct device_node *parent)
+{}
+#endif
 void gic_secondary_init(unsigned int);
 void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
 void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
@@ -46,6 +55,7 @@ struct gic_chip_data {
 	unsigned int irq_offset;
 	void __iomem *dist_base;
 	void __iomem *cpu_base;
+	struct irq_domain domain;
 };
 #endif
 
-- 
1.7.5.4

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

This adds gic initialization using device tree data. The initialization
functions are intended to be called by a generic OF interrupt
controller parsing function once the right pieces are in place.

PPIs are handled using 3rd cell of interrupts properties to specify the cpu
mask the PPI is assigned to.

Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
---
 Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
 arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
 arch/arm/include/asm/hardware/gic.h           |   10 +++++
 3 files changed, 114 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
new file mode 100644
index 0000000..6c513de
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -0,0 +1,53 @@
+* ARM Generic Interrupt Controller
+
+ARM SMP cores are often associated with a GIC, providing per processor
+interrupts (PPI), shared processor interrupts (SPI) and software
+generated interrupts (SGI).
+
+Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
+Secondary GICs are cascaded into the upward interrupt controller and do not
+have PPIs or SGIs.
+
+Main node required properties:
+
+- compatible : should be one of:
+	"arm,cortex-a9-gic"
+	"arm,arm11mp-gic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source.  The type shall be a <u32> and the value shall be 3.
+
+  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
+  for PPIs.
+
+  The 2nd cell is the level-sense information, encoded as follows:
+                    1 = low-to-high edge triggered
+                    2 = high-to-low edge triggered
+                    4 = active high level-sensitive
+                    8 = active low level-sensitive
+
+  Only values of 1 and 4 are valid for GIC 1.0 spec.
+
+  The 3rd cell contains the mask of the cpu number for the interrupt source.
+  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
+  be 0 for PPIs.
+
+- reg : Specifies base physical address(s) and size of the GIC registers. The
+  first 2 values are the GIC distributor register base and size. The 2nd 2
+  values are the GIC cpu interface register base and size.
+
+Optional
+- interrupts	: Interrupt source of the parent interrupt controller. Only
+  present on secondary GICs.
+
+Example:
+
+	intc: interrupt-controller@fff11000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		interrupt-controller;
+		reg = <0xfff11000 0x1000>,
+		      <0xfff10100 0x100>;
+	};
+
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index d1ccc72..14de380 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -28,6 +28,10 @@
 #include <linux/smp.h>
 #include <linux/cpumask.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
 
 #include <asm/irq.h>
 #include <asm/mach/irq.h>
@@ -255,6 +259,15 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
 	irq_set_chained_handler(irq, gic_handle_cascade_irq);
 }
 
+static int gic_irq_count(void __iomem *dist_base)
+{
+	int gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
+	gic_irqs = (gic_irqs + 1) * 32;
+	if (gic_irqs > 1020)
+		gic_irqs = 1020;
+	return gic_irqs;
+}
+
 static void __init gic_dist_init(struct gic_chip_data *gic,
 	unsigned int irq_start)
 {
@@ -277,10 +290,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
 	 * Find out how many interrupts are supported.
 	 * The GIC only supports up to 1020 interrupt sources.
 	 */
-	gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
-	gic_irqs = (gic_irqs + 1) * 32;
-	if (gic_irqs > 1020)
-		gic_irqs = 1020;
+	gic_irqs = gic_irq_count(base);
 
 	/*
 	 * Set all global interrupts to be level triggered, active low.
@@ -405,3 +415,40 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 	writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
 }
 #endif
+
+#ifdef CONFIG_OF
+static int gic_cnt __initdata = 0;
+
+extern struct irq_domain_ops irq_domain_simple_ops;
+
+void __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+	void __iomem *cpu_base;
+	void __iomem *dist_base;
+	int irq;
+	struct irq_domain *domain = &gic_data[gic_cnt].domain;
+
+	if (WARN_ON(!node))
+		return;
+
+	dist_base = of_iomap(node, 0);
+	WARN(!dist_base, "unable to map gic dist registers\n");
+
+	cpu_base = of_iomap(node, 1);
+	WARN(!cpu_base, "unable to map gic cpu registers\n");
+
+	domain->nr_irq = gic_irq_count(dist_base);
+	domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
+	domain->of_node = of_node_get(node);
+	domain->ops = &irq_domain_simple_ops;
+	irq_domain_add(domain);
+
+	gic_init(gic_cnt, domain->irq_base, dist_base, cpu_base);
+
+	if (parent) {
+		irq = irq_of_parse_and_map(node, 0);
+		gic_cascade_irq(gic_cnt, irq);
+	}
+	gic_cnt++;
+}
+#endif
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 435d3f8..ea1ca08 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -33,10 +33,19 @@
 #define GIC_DIST_SOFTINT		0xf00
 
 #ifndef __ASSEMBLY__
+#include <linux/irqdomain.h>
+
 extern void __iomem *gic_cpu_base_addr;
 extern struct irq_chip gic_arch_extn;
 
 void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+#ifdef CONFIG_OF
+void gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline void gic_of_init(struct device_node *node,
+			       struct device_node *parent)
+{}
+#endif
 void gic_secondary_init(unsigned int);
 void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
 void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
@@ -46,6 +55,7 @@ struct gic_chip_data {
 	unsigned int irq_offset;
 	void __iomem *dist_base;
 	void __iomem *cpu_base;
+	struct irq_domain domain;
 };
 #endif
 
-- 
1.7.5.4

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

This adds gic initialization using device tree data. The initialization
functions are intended to be called by a generic OF interrupt
controller parsing function once the right pieces are in place.

PPIs are handled using 3rd cell of interrupts properties to specify the cpu
mask the PPI is assigned to.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
 arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
 arch/arm/include/asm/hardware/gic.h           |   10 +++++
 3 files changed, 114 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
new file mode 100644
index 0000000..6c513de
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -0,0 +1,53 @@
+* ARM Generic Interrupt Controller
+
+ARM SMP cores are often associated with a GIC, providing per processor
+interrupts (PPI), shared processor interrupts (SPI) and software
+generated interrupts (SGI).
+
+Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
+Secondary GICs are cascaded into the upward interrupt controller and do not
+have PPIs or SGIs.
+
+Main node required properties:
+
+- compatible : should be one of:
+	"arm,cortex-a9-gic"
+	"arm,arm11mp-gic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source.  The type shall be a <u32> and the value shall be 3.
+
+  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
+  for PPIs.
+
+  The 2nd cell is the level-sense information, encoded as follows:
+                    1 = low-to-high edge triggered
+                    2 = high-to-low edge triggered
+                    4 = active high level-sensitive
+                    8 = active low level-sensitive
+
+  Only values of 1 and 4 are valid for GIC 1.0 spec.
+
+  The 3rd cell contains the mask of the cpu number for the interrupt source.
+  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
+  be 0 for PPIs.
+
+- reg : Specifies base physical address(s) and size of the GIC registers. The
+  first 2 values are the GIC distributor register base and size. The 2nd 2
+  values are the GIC cpu interface register base and size.
+
+Optional
+- interrupts	: Interrupt source of the parent interrupt controller. Only
+  present on secondary GICs.
+
+Example:
+
+	intc: interrupt-controller at fff11000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <1>;
+		interrupt-controller;
+		reg = <0xfff11000 0x1000>,
+		      <0xfff10100 0x100>;
+	};
+
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index d1ccc72..14de380 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -28,6 +28,10 @@
 #include <linux/smp.h>
 #include <linux/cpumask.h>
 #include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/irqdomain.h>
 
 #include <asm/irq.h>
 #include <asm/mach/irq.h>
@@ -255,6 +259,15 @@ void __init gic_cascade_irq(unsigned int gic_nr, unsigned int irq)
 	irq_set_chained_handler(irq, gic_handle_cascade_irq);
 }
 
+static int gic_irq_count(void __iomem *dist_base)
+{
+	int gic_irqs = readl_relaxed(dist_base + GIC_DIST_CTR) & 0x1f;
+	gic_irqs = (gic_irqs + 1) * 32;
+	if (gic_irqs > 1020)
+		gic_irqs = 1020;
+	return gic_irqs;
+}
+
 static void __init gic_dist_init(struct gic_chip_data *gic,
 	unsigned int irq_start)
 {
@@ -277,10 +290,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,
 	 * Find out how many interrupts are supported.
 	 * The GIC only supports up to 1020 interrupt sources.
 	 */
-	gic_irqs = readl_relaxed(base + GIC_DIST_CTR) & 0x1f;
-	gic_irqs = (gic_irqs + 1) * 32;
-	if (gic_irqs > 1020)
-		gic_irqs = 1020;
+	gic_irqs = gic_irq_count(base);
 
 	/*
 	 * Set all global interrupts to be level triggered, active low.
@@ -405,3 +415,40 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 	writel_relaxed(map << 16 | irq, gic_data[0].dist_base + GIC_DIST_SOFTINT);
 }
 #endif
+
+#ifdef CONFIG_OF
+static int gic_cnt __initdata = 0;
+
+extern struct irq_domain_ops irq_domain_simple_ops;
+
+void __init gic_of_init(struct device_node *node, struct device_node *parent)
+{
+	void __iomem *cpu_base;
+	void __iomem *dist_base;
+	int irq;
+	struct irq_domain *domain = &gic_data[gic_cnt].domain;
+
+	if (WARN_ON(!node))
+		return;
+
+	dist_base = of_iomap(node, 0);
+	WARN(!dist_base, "unable to map gic dist registers\n");
+
+	cpu_base = of_iomap(node, 1);
+	WARN(!cpu_base, "unable to map gic cpu registers\n");
+
+	domain->nr_irq = gic_irq_count(dist_base);
+	domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
+	domain->of_node = of_node_get(node);
+	domain->ops = &irq_domain_simple_ops;
+	irq_domain_add(domain);
+
+	gic_init(gic_cnt, domain->irq_base, dist_base, cpu_base);
+
+	if (parent) {
+		irq = irq_of_parse_and_map(node, 0);
+		gic_cascade_irq(gic_cnt, irq);
+	}
+	gic_cnt++;
+}
+#endif
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 435d3f8..ea1ca08 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -33,10 +33,19 @@
 #define GIC_DIST_SOFTINT		0xf00
 
 #ifndef __ASSEMBLY__
+#include <linux/irqdomain.h>
+
 extern void __iomem *gic_cpu_base_addr;
 extern struct irq_chip gic_arch_extn;
 
 void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+#ifdef CONFIG_OF
+void gic_of_init(struct device_node *node, struct device_node *parent);
+#else
+static inline void gic_of_init(struct device_node *node,
+			       struct device_node *parent)
+{}
+#endif
 void gic_secondary_init(unsigned int);
 void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
 void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
@@ -46,6 +55,7 @@ struct gic_chip_data {
 	unsigned int irq_offset;
 	void __iomem *dist_base;
 	void __iomem *cpu_base;
+	struct irq_domain domain;
 };
 #endif
 
-- 
1.7.5.4

Re: [PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Thomas Gleixner]

On Wed, 14 Sep 2011, Rob Herring wrote:

> From: Rob Herring <rob.herring@calxeda.com>
> 
> irq_data will normally exist, so the domain was prevented from being set.
> The simple domain code did not hit this as nr_irq is always 0.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Thomas Gleixner <tglx@linutronix.de>

I take this and 1/5 through irq/urgent

Thanks,

	tglx

> ---
>  kernel/irq/irqdomain.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index d5828da..84f4110 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
>  	 */
>  	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
>  		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> -		if (d || d->domain) {
> +		if (d && d->domain) {
>  			/* things are broken; just report, don't clean up */
>  			WARN(1, "error: irq_desc already assigned to a domain");
>  			return;
> -- 
> 1.7.5.4
> 
> 

Re: [PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Thomas Gleixner]

On Wed, 14 Sep 2011, Rob Herring wrote:

> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> irq_data will normally exist, so the domain was prevented from being set.
> The simple domain code did not hit this as nr_irq is always 0.
> 
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>

I take this and 1/5 through irq/urgent

Thanks,

	tglx

> ---
>  kernel/irq/irqdomain.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index d5828da..84f4110 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
>  	 */
>  	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
>  		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> -		if (d || d->domain) {
> +		if (d && d->domain) {
>  			/* things are broken; just report, don't clean up */
>  			WARN(1, "error: irq_desc already assigned to a domain");
>  			return;
> -- 
> 1.7.5.4
> 
> 

[PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Thomas Gleixner]

On Wed, 14 Sep 2011, Rob Herring wrote:

> From: Rob Herring <rob.herring@calxeda.com>
> 
> irq_data will normally exist, so the domain was prevented from being set.
> The simple domain code did not hit this as nr_irq is always 0.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Thomas Gleixner <tglx@linutronix.de>

I take this and 1/5 through irq/urgent

Thanks,

	tglx

> ---
>  kernel/irq/irqdomain.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> index d5828da..84f4110 100644
> --- a/kernel/irq/irqdomain.c
> +++ b/kernel/irq/irqdomain.c
> @@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
>  	 */
>  	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
>  		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> -		if (d || d->domain) {
> +		if (d && d->domain) {
>  			/* things are broken; just report, don't clean up */
>  			WARN(1, "error: irq_desc already assigned to a domain");
>  			return;
> -- 
> 1.7.5.4
> 
> 

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Marc Zyngier]

On 14/09/11 17:31, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..6c513de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,53 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> +	"arm,cortex-a9-gic"
> +	"arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> +
> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> +  for PPIs.
> +
> +  The 2nd cell is the level-sense information, encoded as follows:
> +                    1 = low-to-high edge triggered
> +                    2 = high-to-low edge triggered
> +                    4 = active high level-sensitive
> +                    8 = active low level-sensitive
> +
> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> +
> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> +  be 0 for PPIs.
     ^^^^^^^^^^^^^

Typo here ? The way I understand it, it should read "For PPIs, this
value shall be the mask of the possible CPU numbers for the interrupt
source" (or something to similar effect...).

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Marc Zyngier]

On 14/09/11 17:31, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..6c513de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,53 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> +	"arm,cortex-a9-gic"
> +	"arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> +
> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> +  for PPIs.
> +
> +  The 2nd cell is the level-sense information, encoded as follows:
> +                    1 = low-to-high edge triggered
> +                    2 = high-to-low edge triggered
> +                    4 = active high level-sensitive
> +                    8 = active low level-sensitive
> +
> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> +
> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> +  be 0 for PPIs.
     ^^^^^^^^^^^^^

Typo here ? The way I understand it, it should read "For PPIs, this
value shall be the mask of the possible CPU numbers for the interrupt
source" (or something to similar effect...).

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 5/5] ARM: gic: add OF based initialization

[Marc Zyngier]

On 14/09/11 17:31, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..6c513de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,53 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> +	"arm,cortex-a9-gic"
> +	"arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> +
> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> +  for PPIs.
> +
> +  The 2nd cell is the level-sense information, encoded as follows:
> +                    1 = low-to-high edge triggered
> +                    2 = high-to-low edge triggered
> +                    4 = active high level-sensitive
> +                    8 = active low level-sensitive
> +
> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> +
> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> +  be 0 for PPIs.
     ^^^^^^^^^^^^^

Typo here ? The way I understand it, it should read "For PPIs, this
value shall be the mask of the possible CPU numbers for the interrupt
source" (or something to similar effect...).

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Marc,

On 09/14/2011 12:46 PM, Marc Zyngier wrote:
> On 14/09/11 17:31, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> ---
>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> new file mode 100644
>> index 0000000..6c513de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> @@ -0,0 +1,53 @@
>> +* ARM Generic Interrupt Controller
>> +
>> +ARM SMP cores are often associated with a GIC, providing per processor
>> +interrupts (PPI), shared processor interrupts (SPI) and software
>> +generated interrupts (SGI).
>> +
>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>> +have PPIs or SGIs.
>> +
>> +Main node required properties:
>> +
>> +- compatible : should be one of:
>> +	"arm,cortex-a9-gic"
>> +	"arm,arm11mp-gic"
>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>> +
>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>> +  for PPIs.
>> +
>> +  The 2nd cell is the level-sense information, encoded as follows:
>> +                    1 = low-to-high edge triggered
>> +                    2 = high-to-low edge triggered
>> +                    4 = active high level-sensitive
>> +                    8 = active low level-sensitive
>> +
>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>> +
>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>> +  be 0 for PPIs.
>      ^^^^^^^^^^^^^
> 
> Typo here ? The way I understand it, it should read "For PPIs, this
> value shall be the mask of the possible CPU numbers for the interrupt
> source" (or something to similar effect...).
> 

Cut and paste error. This sentence goes in the previous paragraph. What
I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
edge/level on PPIs (that is always true, right?). I probably should also
add 0 in the list of values.

I take it you are otherwise fine with this binding?

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Marc,

On 09/14/2011 12:46 PM, Marc Zyngier wrote:
> On 14/09/11 17:31, Rob Herring wrote:
>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> new file mode 100644
>> index 0000000..6c513de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> @@ -0,0 +1,53 @@
>> +* ARM Generic Interrupt Controller
>> +
>> +ARM SMP cores are often associated with a GIC, providing per processor
>> +interrupts (PPI), shared processor interrupts (SPI) and software
>> +generated interrupts (SGI).
>> +
>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>> +have PPIs or SGIs.
>> +
>> +Main node required properties:
>> +
>> +- compatible : should be one of:
>> +	"arm,cortex-a9-gic"
>> +	"arm,arm11mp-gic"
>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>> +
>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>> +  for PPIs.
>> +
>> +  The 2nd cell is the level-sense information, encoded as follows:
>> +                    1 = low-to-high edge triggered
>> +                    2 = high-to-low edge triggered
>> +                    4 = active high level-sensitive
>> +                    8 = active low level-sensitive
>> +
>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>> +
>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>> +  be 0 for PPIs.
>      ^^^^^^^^^^^^^
> 
> Typo here ? The way I understand it, it should read "For PPIs, this
> value shall be the mask of the possible CPU numbers for the interrupt
> source" (or something to similar effect...).
> 

Cut and paste error. This sentence goes in the previous paragraph. What
I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
edge/level on PPIs (that is always true, right?). I probably should also
add 0 in the list of values.

I take it you are otherwise fine with this binding?

Rob

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Marc,

On 09/14/2011 12:46 PM, Marc Zyngier wrote:
> On 14/09/11 17:31, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> ---
>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>> new file mode 100644
>> index 0000000..6c513de
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>> @@ -0,0 +1,53 @@
>> +* ARM Generic Interrupt Controller
>> +
>> +ARM SMP cores are often associated with a GIC, providing per processor
>> +interrupts (PPI), shared processor interrupts (SPI) and software
>> +generated interrupts (SGI).
>> +
>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>> +have PPIs or SGIs.
>> +
>> +Main node required properties:
>> +
>> +- compatible : should be one of:
>> +	"arm,cortex-a9-gic"
>> +	"arm,arm11mp-gic"
>> +- interrupt-controller : Identifies the node as an interrupt controller
>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>> +
>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>> +  for PPIs.
>> +
>> +  The 2nd cell is the level-sense information, encoded as follows:
>> +                    1 = low-to-high edge triggered
>> +                    2 = high-to-low edge triggered
>> +                    4 = active high level-sensitive
>> +                    8 = active low level-sensitive
>> +
>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>> +
>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>> +  be 0 for PPIs.
>      ^^^^^^^^^^^^^
> 
> Typo here ? The way I understand it, it should read "For PPIs, this
> value shall be the mask of the possible CPU numbers for the interrupt
> source" (or something to similar effect...).
> 

Cut and paste error. This sentence goes in the previous paragraph. What
I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
edge/level on PPIs (that is always true, right?). I probably should also
add 0 in the list of values.

I take it you are otherwise fine with this binding?

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Marc Zyngier]

Hi Rob,

On 14/09/11 18:57, Rob Herring wrote:
> Marc,
> 
> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>> On 14/09/11 17:31, Rob Herring wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>> new file mode 100644
>>> index 0000000..6c513de
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>> @@ -0,0 +1,53 @@
>>> +* ARM Generic Interrupt Controller
>>> +
>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>> +generated interrupts (SGI).
>>> +
>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>> +have PPIs or SGIs.
>>> +
>>> +Main node required properties:
>>> +
>>> +- compatible : should be one of:
>>> +	"arm,cortex-a9-gic"
>>> +	"arm,arm11mp-gic"
>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>>> +
>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>> +  for PPIs.
>>> +
>>> +  The 2nd cell is the level-sense information, encoded as follows:
>>> +                    1 = low-to-high edge triggered
>>> +                    2 = high-to-low edge triggered
>>> +                    4 = active high level-sensitive
>>> +                    8 = active low level-sensitive
>>> +
>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>>> +
>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>> +  be 0 for PPIs.
>>      ^^^^^^^^^^^^^
>>
>> Typo here ? The way I understand it, it should read "For PPIs, this
>> value shall be the mask of the possible CPU numbers for the interrupt
>> source" (or something to similar effect...).
>>
> 
> Cut and paste error. This sentence goes in the previous paragraph. What
> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
> edge/level on PPIs (that is always true, right?). I probably should also
> add 0 in the list of values.

Ah, right. It makes sense indeed. You're correct about PPIs polarity,
this is defined by the hardware and cannot be configured. But it may be
interesting to have the DT to reflect the way the hardware is actually
configured (on the Cortex-A9, some PPIs are configured active-low, and
others are rising-edge).

> I take it you are otherwise fine with this binding?

I very much like the fact that it (or at least that's the way I
understand it...) allows for a very compact expression of peripherals
connected to PPIs.

What I'd like to write is the following:

twd@1f000600 {
	compatible = "arm,11mpcore-twd";
	reg = <0x1f000600 0x100>;
	interrupt-parent = <&intc>;
	interrupt = <29 0 0xf>;
}

where 0xf would indicate that the TWD is connected to all four cores. Is
that correct?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Marc Zyngier]

Hi Rob,

On 14/09/11 18:57, Rob Herring wrote:
> Marc,
> 
> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>> On 14/09/11 17:31, Rob Herring wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>> new file mode 100644
>>> index 0000000..6c513de
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>> @@ -0,0 +1,53 @@
>>> +* ARM Generic Interrupt Controller
>>> +
>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>> +generated interrupts (SGI).
>>> +
>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>> +have PPIs or SGIs.
>>> +
>>> +Main node required properties:
>>> +
>>> +- compatible : should be one of:
>>> +	"arm,cortex-a9-gic"
>>> +	"arm,arm11mp-gic"
>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>>> +
>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>> +  for PPIs.
>>> +
>>> +  The 2nd cell is the level-sense information, encoded as follows:
>>> +                    1 = low-to-high edge triggered
>>> +                    2 = high-to-low edge triggered
>>> +                    4 = active high level-sensitive
>>> +                    8 = active low level-sensitive
>>> +
>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>>> +
>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>> +  be 0 for PPIs.
>>      ^^^^^^^^^^^^^
>>
>> Typo here ? The way I understand it, it should read "For PPIs, this
>> value shall be the mask of the possible CPU numbers for the interrupt
>> source" (or something to similar effect...).
>>
> 
> Cut and paste error. This sentence goes in the previous paragraph. What
> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
> edge/level on PPIs (that is always true, right?). I probably should also
> add 0 in the list of values.

Ah, right. It makes sense indeed. You're correct about PPIs polarity,
this is defined by the hardware and cannot be configured. But it may be
interesting to have the DT to reflect the way the hardware is actually
configured (on the Cortex-A9, some PPIs are configured active-low, and
others are rising-edge).

> I take it you are otherwise fine with this binding?

I very much like the fact that it (or at least that's the way I
understand it...) allows for a very compact expression of peripherals
connected to PPIs.

What I'd like to write is the following:

twd@1f000600 {
	compatible = "arm,11mpcore-twd";
	reg = <0x1f000600 0x100>;
	interrupt-parent = <&intc>;
	interrupt = <29 0 0xf>;
}

where 0xf would indicate that the TWD is connected to all four cores. Is
that correct?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH 5/5] ARM: gic: add OF based initialization

[Marc Zyngier]

Hi Rob,

On 14/09/11 18:57, Rob Herring wrote:
> Marc,
> 
> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>> On 14/09/11 17:31, Rob Herring wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>> new file mode 100644
>>> index 0000000..6c513de
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>> @@ -0,0 +1,53 @@
>>> +* ARM Generic Interrupt Controller
>>> +
>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>> +generated interrupts (SGI).
>>> +
>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>> +have PPIs or SGIs.
>>> +
>>> +Main node required properties:
>>> +
>>> +- compatible : should be one of:
>>> +	"arm,cortex-a9-gic"
>>> +	"arm,arm11mp-gic"
>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>>> +
>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>> +  for PPIs.
>>> +
>>> +  The 2nd cell is the level-sense information, encoded as follows:
>>> +                    1 = low-to-high edge triggered
>>> +                    2 = high-to-low edge triggered
>>> +                    4 = active high level-sensitive
>>> +                    8 = active low level-sensitive
>>> +
>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>>> +
>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>> +  be 0 for PPIs.
>>      ^^^^^^^^^^^^^
>>
>> Typo here ? The way I understand it, it should read "For PPIs, this
>> value shall be the mask of the possible CPU numbers for the interrupt
>> source" (or something to similar effect...).
>>
> 
> Cut and paste error. This sentence goes in the previous paragraph. What
> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
> edge/level on PPIs (that is always true, right?). I probably should also
> add 0 in the list of values.

Ah, right. It makes sense indeed. You're correct about PPIs polarity,
this is defined by the hardware and cannot be configured. But it may be
interesting to have the DT to reflect the way the hardware is actually
configured (on the Cortex-A9, some PPIs are configured active-low, and
others are rising-edge).

> I take it you are otherwise fine with this binding?

I very much like the fact that it (or at least that's the way I
understand it...) allows for a very compact expression of peripherals
connected to PPIs.

What I'd like to write is the following:

twd at 1f000600 {
	compatible = "arm,11mpcore-twd";
	reg = <0x1f000600 0x100>;
	interrupt-parent = <&intc>;
	interrupt = <29 0 0xf>;
}

where 0xf would indicate that the TWD is connected to all four cores. Is
that correct?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> Hi Rob,
> 
> On 14/09/11 18:57, Rob Herring wrote:
>> Marc,
>>
>> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>>> On 14/09/11 17:31, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>>> new file mode 100644
>>>> index 0000000..6c513de
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>>> @@ -0,0 +1,53 @@
>>>> +* ARM Generic Interrupt Controller
>>>> +
>>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>>> +generated interrupts (SGI).
>>>> +
>>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>>> +have PPIs or SGIs.
>>>> +
>>>> +Main node required properties:
>>>> +
>>>> +- compatible : should be one of:
>>>> +	"arm,cortex-a9-gic"
>>>> +	"arm,arm11mp-gic"
>>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>>>> +
>>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>>> +  for PPIs.
>>>> +
>>>> +  The 2nd cell is the level-sense information, encoded as follows:
>>>> +                    1 = low-to-high edge triggered
>>>> +                    2 = high-to-low edge triggered
>>>> +                    4 = active high level-sensitive
>>>> +                    8 = active low level-sensitive
>>>> +
>>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>>>> +
>>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>>> +  be 0 for PPIs.
>>>      ^^^^^^^^^^^^^
>>>
>>> Typo here ? The way I understand it, it should read "For PPIs, this
>>> value shall be the mask of the possible CPU numbers for the interrupt
>>> source" (or something to similar effect...).
>>>
>>
>> Cut and paste error. This sentence goes in the previous paragraph. What
>> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
>> edge/level on PPIs (that is always true, right?). I probably should also
>> add 0 in the list of values.
> 
> Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> this is defined by the hardware and cannot be configured. But it may be
> interesting to have the DT to reflect the way the hardware is actually
> configured (on the Cortex-A9, some PPIs are configured active-low, and
> others are rising-edge).

So we should allow specifying what it is as the OS may need to know that.

> 
>> I take it you are otherwise fine with this binding?
> 
> I very much like the fact that it (or at least that's the way I
> understand it...) allows for a very compact expression of peripherals
> connected to PPIs.
> 
> What I'd like to write is the following:
> 
> twd@1f000600 {
> 	compatible = "arm,11mpcore-twd";
> 	reg = <0x1f000600 0x100>;
> 	interrupt-parent = <&intc>;
> 	interrupt = <29 0 0xf>;
> }
> 
> where 0xf would indicate that the TWD is connected to all four cores. Is
> that correct?
> 
Yes, that's exactly why I did a mask and is what I have for twd on
highbank. Also, I specified SPIs as 0 specifically so no one gets the
idea to use the mask to set the affinity.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> Hi Rob,
> 
> On 14/09/11 18:57, Rob Herring wrote:
>> Marc,
>>
>> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>>> On 14/09/11 17:31, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>>> new file mode 100644
>>>> index 0000000..6c513de
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>>> @@ -0,0 +1,53 @@
>>>> +* ARM Generic Interrupt Controller
>>>> +
>>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>>> +generated interrupts (SGI).
>>>> +
>>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>>> +have PPIs or SGIs.
>>>> +
>>>> +Main node required properties:
>>>> +
>>>> +- compatible : should be one of:
>>>> +	"arm,cortex-a9-gic"
>>>> +	"arm,arm11mp-gic"
>>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>>>> +
>>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>>> +  for PPIs.
>>>> +
>>>> +  The 2nd cell is the level-sense information, encoded as follows:
>>>> +                    1 = low-to-high edge triggered
>>>> +                    2 = high-to-low edge triggered
>>>> +                    4 = active high level-sensitive
>>>> +                    8 = active low level-sensitive
>>>> +
>>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>>>> +
>>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>>> +  be 0 for PPIs.
>>>      ^^^^^^^^^^^^^
>>>
>>> Typo here ? The way I understand it, it should read "For PPIs, this
>>> value shall be the mask of the possible CPU numbers for the interrupt
>>> source" (or something to similar effect...).
>>>
>>
>> Cut and paste error. This sentence goes in the previous paragraph. What
>> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
>> edge/level on PPIs (that is always true, right?). I probably should also
>> add 0 in the list of values.
> 
> Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> this is defined by the hardware and cannot be configured. But it may be
> interesting to have the DT to reflect the way the hardware is actually
> configured (on the Cortex-A9, some PPIs are configured active-low, and
> others are rising-edge).

So we should allow specifying what it is as the OS may need to know that.

> 
>> I take it you are otherwise fine with this binding?
> 
> I very much like the fact that it (or at least that's the way I
> understand it...) allows for a very compact expression of peripherals
> connected to PPIs.
> 
> What I'd like to write is the following:
> 
> twd@1f000600 {
> 	compatible = "arm,11mpcore-twd";
> 	reg = <0x1f000600 0x100>;
> 	interrupt-parent = <&intc>;
> 	interrupt = <29 0 0xf>;
> }
> 
> where 0xf would indicate that the TWD is connected to all four cores. Is
> that correct?
> 
Yes, that's exactly why I did a mask and is what I have for twd on
highbank. Also, I specified SPIs as 0 specifically so no one gets the
idea to use the mask to set the affinity.

Rob

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> Hi Rob,
> 
> On 14/09/11 18:57, Rob Herring wrote:
>> Marc,
>>
>> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>>> On 14/09/11 17:31, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>>> new file mode 100644
>>>> index 0000000..6c513de
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>>> @@ -0,0 +1,53 @@
>>>> +* ARM Generic Interrupt Controller
>>>> +
>>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>>> +generated interrupts (SGI).
>>>> +
>>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>>> +have PPIs or SGIs.
>>>> +
>>>> +Main node required properties:
>>>> +
>>>> +- compatible : should be one of:
>>>> +	"arm,cortex-a9-gic"
>>>> +	"arm,arm11mp-gic"
>>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
>>>> +
>>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>>> +  for PPIs.
>>>> +
>>>> +  The 2nd cell is the level-sense information, encoded as follows:
>>>> +                    1 = low-to-high edge triggered
>>>> +                    2 = high-to-low edge triggered
>>>> +                    4 = active high level-sensitive
>>>> +                    8 = active low level-sensitive
>>>> +
>>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
>>>> +
>>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
>>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>>> +  be 0 for PPIs.
>>>      ^^^^^^^^^^^^^
>>>
>>> Typo here ? The way I understand it, it should read "For PPIs, this
>>> value shall be the mask of the possible CPU numbers for the interrupt
>>> source" (or something to similar effect...).
>>>
>>
>> Cut and paste error. This sentence goes in the previous paragraph. What
>> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
>> edge/level on PPIs (that is always true, right?). I probably should also
>> add 0 in the list of values.
> 
> Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> this is defined by the hardware and cannot be configured. But it may be
> interesting to have the DT to reflect the way the hardware is actually
> configured (on the Cortex-A9, some PPIs are configured active-low, and
> others are rising-edge).

So we should allow specifying what it is as the OS may need to know that.

> 
>> I take it you are otherwise fine with this binding?
> 
> I very much like the fact that it (or at least that's the way I
> understand it...) allows for a very compact expression of peripherals
> connected to PPIs.
> 
> What I'd like to write is the following:
> 
> twd at 1f000600 {
> 	compatible = "arm,11mpcore-twd";
> 	reg = <0x1f000600 0x100>;
> 	interrupt-parent = <&intc>;
> 	interrupt = <29 0 0xf>;
> }
> 
> where 0xf would indicate that the TWD is connected to all four cores. Is
> that correct?
> 
Yes, that's exactly why I did a mask and is what I have for twd on
highbank. Also, I specified SPIs as 0 specifically so no one gets the
idea to use the mask to set the affinity.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Rob,

On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
>
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

[...]


> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index d1ccc72..14de380 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c

[...]

> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
> +{
> +       void __iomem *cpu_base;
> +       void __iomem *dist_base;
> +       int irq;
> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
> +
> +       if (WARN_ON(!node))
> +               return;
> +
> +       dist_base = of_iomap(node, 0);
> +       WARN(!dist_base, "unable to map gic dist registers\n");
> +
> +       cpu_base = of_iomap(node, 1);
> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
> +
> +       domain->nr_irq = gic_irq_count(dist_base);
> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());

For exynos4, all the interrupts originating from GIC are statically
mapped to start from 32 in the linux virq space (GIC SPI interrupts
start from 64). In the above code, since irq_base would be 0 for
exynos4, the interrupt mapping is not working correctly. In your
previous version of the patch, you have given a option to the platform
code to choose the offset. Could that option be added to this series
also. Or a provision to use platform specific translate function
instead of the irq_domain_simple translator.

Thanks,
Thomas.

[...]

[PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Rob,

On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
>
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
> ?Documentation/devicetree/bindings/arm/gic.txt | ? 53 ++++++++++++++++++++++++
> ?arch/arm/common/gic.c ? ? ? ? ? ? ? ? ? ? ? ? | ? 55 +++++++++++++++++++++++--
> ?arch/arm/include/asm/hardware/gic.h ? ? ? ? ? | ? 10 +++++
> ?3 files changed, 114 insertions(+), 4 deletions(-)
> ?create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

[...]


> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index d1ccc72..14de380 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c

[...]

> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
> +{
> + ? ? ? void __iomem *cpu_base;
> + ? ? ? void __iomem *dist_base;
> + ? ? ? int irq;
> + ? ? ? struct irq_domain *domain = &gic_data[gic_cnt].domain;
> +
> + ? ? ? if (WARN_ON(!node))
> + ? ? ? ? ? ? ? return;
> +
> + ? ? ? dist_base = of_iomap(node, 0);
> + ? ? ? WARN(!dist_base, "unable to map gic dist registers\n");
> +
> + ? ? ? cpu_base = of_iomap(node, 1);
> + ? ? ? WARN(!cpu_base, "unable to map gic cpu registers\n");
> +
> + ? ? ? domain->nr_irq = gic_irq_count(dist_base);
> + ? ? ? domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());

For exynos4, all the interrupts originating from GIC are statically
mapped to start from 32 in the linux virq space (GIC SPI interrupts
start from 64). In the above code, since irq_base would be 0 for
exynos4, the interrupt mapping is not working correctly. In your
previous version of the patch, you have given a option to the platform
code to choose the offset. Could that option be added to this series
also. Or a provision to use platform specific translate function
instead of the irq_domain_simple translator.

Thanks,
Thomas.

[...]

Re: [PATCH 0/5] GIC OF bindings

[Jamie Iles]

On Wed, Sep 14, 2011 at 11:31:35AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This series introduces of_irq_init to scan the device tree for interrupt
> controller nodes and call their init functions in proper order. The GIC
> init function is then called from this function. The platform code then
> looks something like this:
> 
> const static struct of_device_id irq_match[] = {
> 	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> 	{}
> };
> 
> static void __init highbank_init_irq(void)
> {
> 	of_irq_init(irq_match);
> }
> 
> The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
> a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
> and suggested by Grant.
> 
> I dropped the public intc_desc struct. The the interrupt controller's node
> and the interrupt parent's node are passed in directly to the controller's
> init function. The linux irq assignment is now done dynamically using
> irq_alloc_descs.

Hi Rob,

This looks really nicely implemented to me.

Reviewed-by: Jamie Iles <jamie@jamieiles.com>

Jamie

[PATCH 0/5] GIC OF bindings

[Jamie Iles]

On Wed, Sep 14, 2011 at 11:31:35AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This series introduces of_irq_init to scan the device tree for interrupt
> controller nodes and call their init functions in proper order. The GIC
> init function is then called from this function. The platform code then
> looks something like this:
> 
> const static struct of_device_id irq_match[] = {
> 	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> 	{}
> };
> 
> static void __init highbank_init_irq(void)
> {
> 	of_irq_init(irq_match);
> }
> 
> The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
> a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
> and suggested by Grant.
> 
> I dropped the public intc_desc struct. The the interrupt controller's node
> and the interrupt parent's node are passed in directly to the controller's
> init function. The linux irq assignment is now done dynamically using
> irq_alloc_descs.

Hi Rob,

This looks really nicely implemented to me.

Reviewed-by: Jamie Iles <jamie@jamieiles.com>

Jamie

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

Hi Rob,

On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> Hi Rob,
>
> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
>> From: Rob Herring<rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>> ---
>>   Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>   arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> [...]
>
>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
>
> [...]
>
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +       void __iomem *cpu_base;
>> +       void __iomem *dist_base;
>> +       int irq;
>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>> +
>> +       if (WARN_ON(!node))
>> +               return;
>> +
>> +       dist_base = of_iomap(node, 0);
>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> +       cpu_base = of_iomap(node, 1);
>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> +       domain->nr_irq = gic_irq_count(dist_base);
>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.

I have another concern on a similar topic.

On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of 
32. Only the internal PPI are between 0 and 31.

For the moment we add 32 to every SoC interrupts in the irq.h define, 
but I'm assuming that this offset calculation should be done thanks to a 
dedicated irq domain for the SPI.
The real HW physical number start at 0, and thus this is that value that 
should be in the irq binding of the device.

So ideally we should have a irq domain for the PPI starting at 0 and 
another one for the SPI starting at 32. Or 32 and 64 for the exynos4 
case, but it looks like the PPI/SPI offset is always 32.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

Hi Rob,

On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> Hi Rob,
>
> On 14 September 2011 22:01, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>> From: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>> ---
>>   Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>   arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> [...]
>
>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
>
> [...]
>
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +       void __iomem *cpu_base;
>> +       void __iomem *dist_base;
>> +       int irq;
>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>> +
>> +       if (WARN_ON(!node))
>> +               return;
>> +
>> +       dist_base = of_iomap(node, 0);
>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> +       cpu_base = of_iomap(node, 1);
>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> +       domain->nr_irq = gic_irq_count(dist_base);
>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.

I have another concern on a similar topic.

On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of 
32. Only the internal PPI are between 0 and 31.

For the moment we add 32 to every SoC interrupts in the irq.h define, 
but I'm assuming that this offset calculation should be done thanks to a 
dedicated irq domain for the SPI.
The real HW physical number start at 0, and thus this is that value that 
should be in the irq binding of the device.

So ideally we should have a irq domain for the PPI starting at 0 and 
another one for the SPI starting at 32. Or 32 and 64 for the exynos4 
case, but it looks like the PPI/SPI offset is always 32.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

Hi Rob,

On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> Hi Rob,
>
> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
>> From: Rob Herring<rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>> ---
>>   Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>   arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>
> [...]
>
>
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
>
> [...]
>
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +       void __iomem *cpu_base;
>> +       void __iomem *dist_base;
>> +       int irq;
>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>> +
>> +       if (WARN_ON(!node))
>> +               return;
>> +
>> +       dist_base = of_iomap(node, 0);
>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> +       cpu_base = of_iomap(node, 1);
>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> +       domain->nr_irq = gic_irq_count(dist_base);
>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.

I have another concern on a similar topic.

On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of 
32. Only the internal PPI are between 0 and 31.

For the moment we add 32 to every SoC interrupts in the irq.h define, 
but I'm assuming that this offset calculation should be done thanks to a 
dedicated irq domain for the SPI.
The real HW physical number start at 0, and thus this is that value that 
should be in the irq binding of the device.

So ideally we should have a irq domain for the PPI starting at 0 and 
another one for the SPI starting at 32. Or 32 and 64 for the exynos4 
case, but it looks like the PPI/SPI offset is always 32.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of  
> 32. Only the internal PPI are between 0 and 31.

SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
numbering given to us by the GIC.

> The real HW physical number start at 0, and thus this is that value that  
> should be in the irq binding of the device.

That depends whether you're counting SPI number or whether you're counting
IRQ number in the GIC interfaces.  SPI0 will be reported to us from the
GIC as 32, not 0, so to start numbering from 0 (which is already frowned
upon for many reasons) we'd have to subtract 32 after checking that the
IRQ is not a SGI nor PPI in the assembly code instead.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of  
> 32. Only the internal PPI are between 0 and 31.

SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
numbering given to us by the GIC.

> The real HW physical number start at 0, and thus this is that value that  
> should be in the irq binding of the device.

That depends whether you're counting SPI number or whether you're counting
IRQ number in the GIC interfaces.  SPI0 will be reported to us from the
GIC as 32, not 0, so to start numbering from 0 (which is already frowned
upon for many reasons) we'd have to subtract 32 after checking that the
IRQ is not a SGI nor PPI in the assembly code instead.

[PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of  
> 32. Only the internal PPI are between 0 and 31.

SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
numbering given to us by the GIC.

> The real HW physical number start at 0, and thus this is that value that  
> should be in the irq binding of the device.

That depends whether you're counting SPI number or whether you're counting
IRQ number in the GIC interfaces.  SPI0 will be reported to us from the
GIC as 32, not 0, so to start numbering from 0 (which is already frowned
upon for many reasons) we'd have to subtract 32 after checking that the
IRQ is not a SGI nor PPI in the assembly code instead.

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Arnd Bergmann]

On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
> 
> Based on initial pseudo code from Grant Likely.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>

Looks good to me,

Acked-by: Arnd Bergmann <arnd@arndb.de>

> +
> +struct intc_desc {
> +       struct list_head        list;
> +       struct device_node      *dev;
> +       struct device_node      *parent;
> +};

One tiny comment: how about naming the parent 'interrupt_parent'? While
reading through the code, I was confused for a short time until I figured
out what this is about.

	Arnd

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Arnd Bergmann]

On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
> 
> Based on initial pseudo code from Grant Likely.
> 
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>

Looks good to me,

Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>

> +
> +struct intc_desc {
> +       struct list_head        list;
> +       struct device_node      *dev;
> +       struct device_node      *parent;
> +};

One tiny comment: how about naming the parent 'interrupt_parent'? While
reading through the code, I was confused for a short time until I figured
out what this is about.

	Arnd

[PATCH 3/5] of/irq: introduce of_irq_init

[Arnd Bergmann]

On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
> 
> Based on initial pseudo code from Grant Likely.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>

Looks good to me,

Acked-by: Arnd Bergmann <arnd@arndb.de>

> +
> +struct intc_desc {
> +       struct list_head        list;
> +       struct device_node      *dev;
> +       struct device_node      *parent;
> +};

One tiny comment: how about naming the parent 'interrupt_parent'? While
reading through the code, I was confused for a short time until I figured
out what this is about.

	Arnd

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Arnd Bergmann]

On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Arnd Bergmann]

On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>

Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>

[PATCH 5/5] ARM: gic: add OF based initialization

[Arnd Bergmann]

On Wednesday 14 September 2011, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 12:29 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>
> SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
> numbering given to us by the GIC.
>
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>
> That depends whether you're counting SPI number or whether you're counting
> IRQ number in the GIC interfaces.  SPI0 will be reported to us from the
> GIC as 32, not 0, so to start numbering from 0 (which is already frowned
> upon for many reasons) we'd have to subtract 32 after checking that the
> IRQ is not a SGI nor PPI in the assembly code instead.

The HW specs is obviously counting the IRQ number at the GIC interface.
That offset is not known outside the MPUSS. Please have a look at the 
OMAP4430 TRM p4761 (NDA vM version).
FWIW, the same numbering scheme is used on tegra2.

My proposal is just to handle the addition within the irq_domain_to_irq, 
so I'm not sure to understand your concern.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 12:29 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>
> SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
> numbering given to us by the GIC.
>
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>
> That depends whether you're counting SPI number or whether you're counting
> IRQ number in the GIC interfaces.  SPI0 will be reported to us from the
> GIC as 32, not 0, so to start numbering from 0 (which is already frowned
> upon for many reasons) we'd have to subtract 32 after checking that the
> IRQ is not a SGI nor PPI in the assembly code instead.

The HW specs is obviously counting the IRQ number at the GIC interface.
That offset is not known outside the MPUSS. Please have a look at the 
OMAP4430 TRM p4761 (NDA vM version).
FWIW, the same numbering scheme is used on tegra2.

My proposal is just to handle the addition within the irq_domain_to_irq, 
so I'm not sure to understand your concern.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 12:29 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>
> SGIs are 0 to 15, PPIs are 16 to 31, and SPIs are 32+ - that's the
> numbering given to us by the GIC.
>
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>
> That depends whether you're counting SPI number or whether you're counting
> IRQ number in the GIC interfaces.  SPI0 will be reported to us from the
> GIC as 32, not 0, so to start numbering from 0 (which is already frowned
> upon for many reasons) we'd have to subtract 32 after checking that the
> IRQ is not a SGI nor PPI in the assembly code instead.

The HW specs is obviously counting the IRQ number at the GIC interface.
That offset is not known outside the MPUSS. Please have a look at the 
OMAP4430 TRM p4761 (NDA vM version).
FWIW, the same numbering scheme is used on tegra2.

My proposal is just to handle the addition within the irq_domain_to_irq, 
so I'm not sure to understand your concern.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
> The HW specs is obviously counting the IRQ number at the GIC interface.
> That offset is not known outside the MPUSS. Please have a look at the  
> OMAP4430 TRM p4761 (NDA vM version).

As far as I know, I have no access to that.  I've certainly never been
pointed to any documentation on OMAP4.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
> The HW specs is obviously counting the IRQ number at the GIC interface.
> That offset is not known outside the MPUSS. Please have a look at the  
> OMAP4430 TRM p4761 (NDA vM version).

As far as I know, I have no access to that.  I've certainly never been
pointed to any documentation on OMAP4.

[PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
> The HW specs is obviously counting the IRQ number at the GIC interface.
> That offset is not known outside the MPUSS. Please have a look at the  
> OMAP4430 TRM p4761 (NDA vM version).

As far as I know, I have no access to that.  I've certainly never been
pointed to any documentation on OMAP4.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> Hi Rob,
> 
> On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> ---
>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> [...]
> 
> 
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
> 
> [...]
> 
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +       void __iomem *cpu_base;
>> +       void __iomem *dist_base;
>> +       int irq;
>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> +
>> +       if (WARN_ON(!node))
>> +               return;
>> +
>> +       dist_base = of_iomap(node, 0);
>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> +       cpu_base = of_iomap(node, 1);
>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> +       domain->nr_irq = gic_irq_count(dist_base);
>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> 
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.
> 

So I guess you have the A9 external nIRQ hooked up to another
controller? Why can't the 0-31 interrupts get mapped to after the gic
interrupts? Ultimately we want h/w irq numbers completely decoupled from
linux irq numbers. So you will want to put that controller in devicetree
and have an DT init function for it as well.

In anycase, there's a simple solution. You just need a call to
irq_alloc_descs to reserve the first 32 interrupts before calling
of_irq_init.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> Hi Rob,
> 
> On 14 September 2011 22:01, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> [...]
> 
> 
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
> 
> [...]
> 
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +       void __iomem *cpu_base;
>> +       void __iomem *dist_base;
>> +       int irq;
>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> +
>> +       if (WARN_ON(!node))
>> +               return;
>> +
>> +       dist_base = of_iomap(node, 0);
>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> +       cpu_base = of_iomap(node, 1);
>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> +       domain->nr_irq = gic_irq_count(dist_base);
>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> 
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.
> 

So I guess you have the A9 external nIRQ hooked up to another
controller? Why can't the 0-31 interrupts get mapped to after the gic
interrupts? Ultimately we want h/w irq numbers completely decoupled from
linux irq numbers. So you will want to put that controller in devicetree
and have an DT init function for it as well.

In anycase, there's a simple solution. You just need a call to
irq_alloc_descs to reserve the first 32 interrupts before calling
of_irq_init.

Rob

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> Hi Rob,
> 
> On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> This adds gic initialization using device tree data. The initialization
>> functions are intended to be called by a generic OF interrupt
>> controller parsing function once the right pieces are in place.
>>
>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>> mask the PPI is assigned to.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> ---
>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> [...]
> 
> 
>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>> index d1ccc72..14de380 100644
>> --- a/arch/arm/common/gic.c
>> +++ b/arch/arm/common/gic.c
> 
> [...]
> 
>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> +{
>> +       void __iomem *cpu_base;
>> +       void __iomem *dist_base;
>> +       int irq;
>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> +
>> +       if (WARN_ON(!node))
>> +               return;
>> +
>> +       dist_base = of_iomap(node, 0);
>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> +
>> +       cpu_base = of_iomap(node, 1);
>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> +
>> +       domain->nr_irq = gic_irq_count(dist_base);
>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> 
> For exynos4, all the interrupts originating from GIC are statically
> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> start from 64). In the above code, since irq_base would be 0 for
> exynos4, the interrupt mapping is not working correctly. In your
> previous version of the patch, you have given a option to the platform
> code to choose the offset. Could that option be added to this series
> also. Or a provision to use platform specific translate function
> instead of the irq_domain_simple translator.
> 

So I guess you have the A9 external nIRQ hooked up to another
controller? Why can't the 0-31 interrupts get mapped to after the gic
interrupts? Ultimately we want h/w irq numbers completely decoupled from
linux irq numbers. So you will want to put that controller in devicetree
and have an DT init function for it as well.

In anycase, there's a simple solution. You just need a call to
irq_alloc_descs to reserve the first 32 interrupts before calling
of_irq_init.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 2:51 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
>> The HW specs is obviously counting the IRQ number at the GIC interface.
>> That offset is not known outside the MPUSS. Please have a look at the
>> OMAP4430 TRM p4761 (NDA vM version).
>
> As far as I know, I have no access to that.  I've certainly never been
> pointed to any documentation on OMAP4.

That's easy to fix since the same information is in the public TRM 
(p3386 in that case). And here is the link:
http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vX.zip

Do not hesitate to ask if you never further information on OMAP SoC.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 2:51 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
>> The HW specs is obviously counting the IRQ number at the GIC interface.
>> That offset is not known outside the MPUSS. Please have a look at the
>> OMAP4430 TRM p4761 (NDA vM version).
>
> As far as I know, I have no access to that.  I've certainly never been
> pointed to any documentation on OMAP4.

That's easy to fix since the same information is in the public TRM 
(p3386 in that case). And here is the link:
http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vX.zip

Do not hesitate to ask if you never further information on OMAP SoC.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 2:51 PM, Russell King - ARM Linux wrote:
> On Thu, Sep 15, 2011 at 02:28:06PM +0200, Cousson, Benoit wrote:
>> The HW specs is obviously counting the IRQ number at the GIC interface.
>> That offset is not known outside the MPUSS. Please have a look at the
>> OMAP4430 TRM p4761 (NDA vM version).
>
> As far as I know, I have no access to that.  I've certainly never been
> pointed to any documentation on OMAP4.

That's easy to fix since the same information is in the public TRM 
(p3386 in that case). And here is the link:
http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.x_PUBLIC_TRM_vX.zip

Do not hesitate to ask if you never further information on OMAP SoC.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Benoit,

On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
>>> From: Rob Herring<rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>> the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>> ---
>>>   Documentation/devicetree/bindings/arm/gic.txt |   53
>>> ++++++++++++++++++++++++
>>>   arch/arm/common/gic.c                         |   55
>>> +++++++++++++++++++++++--
>>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>> *parent)
>>> +{
>>> +       void __iomem *cpu_base;
>>> +       void __iomem *dist_base;
>>> +       int irq;
>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>> +
>>> +       if (WARN_ON(!node))
>>> +               return;
>>> +
>>> +       dist_base = of_iomap(node, 0);
>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> +       cpu_base = of_iomap(node, 1);
>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>> numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
> 32. Only the internal PPI are between 0 and 31.
> 
> For the moment we add 32 to every SoC interrupts in the irq.h define,

Those defines will not be used in the DT case. So the question is
whether to add 32 or not in the DT. Since we have just a single node and
a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
at 32. And from the h/w definition, SPIs always start at 32, so it's in
agreement.

> but I'm assuming that this offset calculation should be done thanks to a
> dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value that
> should be in the irq binding of the device.
> 
> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.
> 

That offset of SPIs is always there. If you have a GIC as a secondary
controller, It will have 32 reserved interrupts and the register layout
is exactly the same as a cpu's GIC.

Since the idea of splitting PPIs for each core out to a flattened linux
irq map has been abandoned, I see no reason to have more than 1 domain
with a simple linear translation. Ultimately, domains will do dynamic
irqdesc allocation and the translation within the gic will be completely
dynamic.

The exynos4 case appears to be another controller hooked up in parallel
to the GIC. The GIC itself is exactly the same as other platforms AFAICT.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Benoit,

On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>>> From: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>> the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>>   Documentation/devicetree/bindings/arm/gic.txt |   53
>>> ++++++++++++++++++++++++
>>>   arch/arm/common/gic.c                         |   55
>>> +++++++++++++++++++++++--
>>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>> *parent)
>>> +{
>>> +       void __iomem *cpu_base;
>>> +       void __iomem *dist_base;
>>> +       int irq;
>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>> +
>>> +       if (WARN_ON(!node))
>>> +               return;
>>> +
>>> +       dist_base = of_iomap(node, 0);
>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> +       cpu_base = of_iomap(node, 1);
>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>> numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
> 32. Only the internal PPI are between 0 and 31.
> 
> For the moment we add 32 to every SoC interrupts in the irq.h define,

Those defines will not be used in the DT case. So the question is
whether to add 32 or not in the DT. Since we have just a single node and
a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
at 32. And from the h/w definition, SPIs always start at 32, so it's in
agreement.

> but I'm assuming that this offset calculation should be done thanks to a
> dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value that
> should be in the irq binding of the device.
> 
> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.
> 

That offset of SPIs is always there. If you have a GIC as a secondary
controller, It will have 32 reserved interrupts and the register layout
is exactly the same as a cpu's GIC.

Since the idea of splitting PPIs for each core out to a flattened linux
irq map has been abandoned, I see no reason to have more than 1 domain
with a simple linear translation. Ultimately, domains will do dynamic
irqdesc allocation and the translation within the gic will be completely
dynamic.

The exynos4 case appears to be another controller hooked up in parallel
to the GIC. The GIC itself is exactly the same as other platforms AFAICT.

Rob

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Benoit,

On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
>>> From: Rob Herring<rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>> the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>> ---
>>>   Documentation/devicetree/bindings/arm/gic.txt |   53
>>> ++++++++++++++++++++++++
>>>   arch/arm/common/gic.c                         |   55
>>> +++++++++++++++++++++++--
>>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>> *parent)
>>> +{
>>> +       void __iomem *cpu_base;
>>> +       void __iomem *dist_base;
>>> +       int irq;
>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>> +
>>> +       if (WARN_ON(!node))
>>> +               return;
>>> +
>>> +       dist_base = of_iomap(node, 0);
>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> +       cpu_base = of_iomap(node, 1);
>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>> numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
> 32. Only the internal PPI are between 0 and 31.
> 
> For the moment we add 32 to every SoC interrupts in the irq.h define,

Those defines will not be used in the DT case. So the question is
whether to add 32 or not in the DT. Since we have just a single node and
a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
at 32. And from the h/w definition, SPIs always start at 32, so it's in
agreement.

> but I'm assuming that this offset calculation should be done thanks to a
> dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value that
> should be in the irq binding of the device.
> 
> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.
> 

That offset of SPIs is always there. If you have a GIC as a secondary
controller, It will have 32 reserved interrupts and the register layout
is exactly the same as a cpu's GIC.

Since the idea of splitting PPIs for each core out to a flattened linux
irq map has been abandoned, I see no reason to have more than 1 domain
with a simple linear translation. Ultimately, domains will do dynamic
irqdesc allocation and the translation within the gic will be completely
dynamic.

The exynos4 case appears to be another controller hooked up in parallel
to the GIC. The GIC itself is exactly the same as other platforms AFAICT.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 3:11 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>> the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>> ++++++++++++++++++++++++
>>>>    arch/arm/common/gic.c                         |   55
>>>> +++++++++++++++++++++++--
>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>> *parent)
>>>> +{
>>>> +       void __iomem *cpu_base;
>>>> +       void __iomem *dist_base;
>>>> +       int irq;
>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> +       if (WARN_ON(!node))
>>>> +               return;
>>>> +
>>>> +       dist_base = of_iomap(node, 0);
>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> +       cpu_base = of_iomap(node, 1);
>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>> numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>
> Those defines will not be used in the DT case. So the question is
> whether to add 32 or not in the DT. Since we have just a single node and
> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
> at 32. And from the h/w definition, SPIs always start at 32, so it's in
> agreement.

This is a agreement inside the MPUSS, but not outside.
Both Tegra and OMAP4 must add an offset to the HW irq number to deal 
with that today.

>> but I'm assuming that this offset calculation should be done thanks to a
>> dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>>
>
> That offset of SPIs is always there. If you have a GIC as a secondary
> controller, It will have 32 reserved interrupts and the register layout
> is exactly the same as a cpu's GIC.

Yep, but that's the GIC view and not the SoC one. My concern is to have 
to tweak the HW number provided by the HW spec in order to add that offset.
If you look at SoC level, the MPUSS is just an IP that can be 
potentially replaced by other one that will not have a GIC. In that case 
you will not change the IRQ mapping at SoC level.
For example if you replace the Dual-cortexA9 by a single CortexA8, then 
all the interrupts will have to be shifted by 32 just because the MPU 
subsystem is different.

Since that offset is dependent of the GIC internals and is not exposed 
outside the MPUSS, it should not be visible by the SoC IPs. And the HW 
spec is exposing exactly that.

> Since the idea of splitting PPIs for each core out to a flattened linux
> irq map has been abandoned, I see no reason to have more than 1 domain
> with a simple linear translation. Ultimately, domains will do dynamic
> irqdesc allocation and the translation within the gic will be completely
> dynamic.

I think the only reason to do that is to separate internal MPU 
interrupts with the external ones that should not have a clue about the GIC.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 3:11 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>   wrote:
>>>> From: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>> the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>> ++++++++++++++++++++++++
>>>>    arch/arm/common/gic.c                         |   55
>>>> +++++++++++++++++++++++--
>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>> *parent)
>>>> +{
>>>> +       void __iomem *cpu_base;
>>>> +       void __iomem *dist_base;
>>>> +       int irq;
>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> +       if (WARN_ON(!node))
>>>> +               return;
>>>> +
>>>> +       dist_base = of_iomap(node, 0);
>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> +       cpu_base = of_iomap(node, 1);
>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>> numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>
> Those defines will not be used in the DT case. So the question is
> whether to add 32 or not in the DT. Since we have just a single node and
> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
> at 32. And from the h/w definition, SPIs always start at 32, so it's in
> agreement.

This is a agreement inside the MPUSS, but not outside.
Both Tegra and OMAP4 must add an offset to the HW irq number to deal 
with that today.

>> but I'm assuming that this offset calculation should be done thanks to a
>> dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>>
>
> That offset of SPIs is always there. If you have a GIC as a secondary
> controller, It will have 32 reserved interrupts and the register layout
> is exactly the same as a cpu's GIC.

Yep, but that's the GIC view and not the SoC one. My concern is to have 
to tweak the HW number provided by the HW spec in order to add that offset.
If you look at SoC level, the MPUSS is just an IP that can be 
potentially replaced by other one that will not have a GIC. In that case 
you will not change the IRQ mapping at SoC level.
For example if you replace the Dual-cortexA9 by a single CortexA8, then 
all the interrupts will have to be shifted by 32 just because the MPU 
subsystem is different.

Since that offset is dependent of the GIC internals and is not exposed 
outside the MPUSS, it should not be visible by the SoC IPs. And the HW 
spec is exposing exactly that.

> Since the idea of splitting PPIs for each core out to a flattened linux
> irq map has been abandoned, I see no reason to have more than 1 domain
> with a simple linear translation. Ultimately, domains will do dynamic
> irqdesc allocation and the translation within the gic will be completely
> dynamic.

I think the only reason to do that is to separate internal MPU 
interrupts with the external ones that should not have a clue about the GIC.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 3:11 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>> the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>> ---
>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>> ++++++++++++++++++++++++
>>>>    arch/arm/common/gic.c                         |   55
>>>> +++++++++++++++++++++++--
>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>> *parent)
>>>> +{
>>>> +       void __iomem *cpu_base;
>>>> +       void __iomem *dist_base;
>>>> +       int irq;
>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> +       if (WARN_ON(!node))
>>>> +               return;
>>>> +
>>>> +       dist_base = of_iomap(node, 0);
>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> +       cpu_base = of_iomap(node, 1);
>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>> numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>> 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>
> Those defines will not be used in the DT case. So the question is
> whether to add 32 or not in the DT. Since we have just a single node and
> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
> at 32. And from the h/w definition, SPIs always start at 32, so it's in
> agreement.

This is a agreement inside the MPUSS, but not outside.
Both Tegra and OMAP4 must add an offset to the HW irq number to deal 
with that today.

>> but I'm assuming that this offset calculation should be done thanks to a
>> dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value that
>> should be in the irq binding of the device.
>>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>>
>
> That offset of SPIs is always there. If you have a GIC as a secondary
> controller, It will have 32 reserved interrupts and the register layout
> is exactly the same as a cpu's GIC.

Yep, but that's the GIC view and not the SoC one. My concern is to have 
to tweak the HW number provided by the HW spec in order to add that offset.
If you look at SoC level, the MPUSS is just an IP that can be 
potentially replaced by other one that will not have a GIC. In that case 
you will not change the IRQ mapping at SoC level.
For example if you replace the Dual-cortexA9 by a single CortexA8, then 
all the interrupts will have to be shifted by 32 just because the MPU 
subsystem is different.

Since that offset is dependent of the GIC internals and is not exposed 
outside the MPUSS, it should not be visible by the SoC IPs. And the HW 
spec is exposing exactly that.

> Since the idea of splitting PPIs for each core out to a flattened linux
> irq map has been abandoned, I see no reason to have more than 1 domain
> with a simple linear translation. Ultimately, domains will do dynamic
> irqdesc allocation and the translation within the gic will be completely
> dynamic.

I think the only reason to do that is to separate internal MPU 
interrupts with the external ones that should not have a clue about the GIC.

Regards,
Benoit

Re: [PATCH 0/5] GIC OF bindings

[Shawn Guo]

On Wed, Sep 14, 2011 at 11:31:35AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This series introduces of_irq_init to scan the device tree for interrupt
> controller nodes and call their init functions in proper order. The GIC
> init function is then called from this function. The platform code then
> looks something like this:
> 
> const static struct of_device_id irq_match[] = {
> 	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> 	{}
> };
> 
> static void __init highbank_init_irq(void)
> {
> 	of_irq_init(irq_match);
> }
> 
> The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
> a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
> and suggested by Grant.
> 
> I dropped the public intc_desc struct. The the interrupt controller's node
> and the interrupt parent's node are passed in directly to the controller's
> init function. The linux irq assignment is now done dynamically using
> irq_alloc_descs.
> 
> The first 2 patches are minor fixes to irqdomains.
> 
> Rob
> 
> Rob Herring (5):
>   irq: add declaration of irq_domain_simple_ops to irqdomain.h
>   irq: fix existing domain check in irq_domain_add
>   of/irq: introduce of_irq_init
>   ARM: gic: allow irq_start to be 0
>   ARM: gic: add OF based initialization
> 
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++
>  arch/arm/common/gic.c                         |   57 +++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++
>  drivers/of/irq.c                              |   96 +++++++++++++++++++++++++
>  include/linux/irqdomain.h                     |    1 +
>  include/linux/of_irq.h                        |    1 +
>  kernel/irq/irqdomain.c                        |    2 +-
>  7 files changed, 214 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

On imx6q:

Tested-by: Shawn Guo <shawn.guo@linaro.org>

-- 
Regards,
Shawn

Re: [PATCH 0/5] GIC OF bindings

[Shawn Guo]

On Wed, Sep 14, 2011 at 11:31:35AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This series introduces of_irq_init to scan the device tree for interrupt
> controller nodes and call their init functions in proper order. The GIC
> init function is then called from this function. The platform code then
> looks something like this:
> 
> const static struct of_device_id irq_match[] = {
> 	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> 	{}
> };
> 
> static void __init highbank_init_irq(void)
> {
> 	of_irq_init(irq_match);
> }
> 
> The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
> a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
> and suggested by Grant.
> 
> I dropped the public intc_desc struct. The the interrupt controller's node
> and the interrupt parent's node are passed in directly to the controller's
> init function. The linux irq assignment is now done dynamically using
> irq_alloc_descs.
> 
> The first 2 patches are minor fixes to irqdomains.
> 
> Rob
> 
> Rob Herring (5):
>   irq: add declaration of irq_domain_simple_ops to irqdomain.h
>   irq: fix existing domain check in irq_domain_add
>   of/irq: introduce of_irq_init
>   ARM: gic: allow irq_start to be 0
>   ARM: gic: add OF based initialization
> 
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++
>  arch/arm/common/gic.c                         |   57 +++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++
>  drivers/of/irq.c                              |   96 +++++++++++++++++++++++++
>  include/linux/irqdomain.h                     |    1 +
>  include/linux/of_irq.h                        |    1 +
>  kernel/irq/irqdomain.c                        |    2 +-
>  7 files changed, 214 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

On imx6q:

Tested-by: Shawn Guo <shawn.guo@linaro.org>

-- 
Regards,
Shawn

[PATCH 0/5] GIC OF bindings

[Shawn Guo]

On Wed, Sep 14, 2011 at 11:31:35AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This series introduces of_irq_init to scan the device tree for interrupt
> controller nodes and call their init functions in proper order. The GIC
> init function is then called from this function. The platform code then
> looks something like this:
> 
> const static struct of_device_id irq_match[] = {
> 	{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
> 	{}
> };
> 
> static void __init highbank_init_irq(void)
> {
> 	of_irq_init(irq_match);
> }
> 
> The binding for GIC PPIs is now done with a 3rd interrupt cell to specify
> a cpu mask for which cpu the PPI is connected to. This was discussed at LPC
> and suggested by Grant.
> 
> I dropped the public intc_desc struct. The the interrupt controller's node
> and the interrupt parent's node are passed in directly to the controller's
> init function. The linux irq assignment is now done dynamically using
> irq_alloc_descs.
> 
> The first 2 patches are minor fixes to irqdomains.
> 
> Rob
> 
> Rob Herring (5):
>   irq: add declaration of irq_domain_simple_ops to irqdomain.h
>   irq: fix existing domain check in irq_domain_add
>   of/irq: introduce of_irq_init
>   ARM: gic: allow irq_start to be 0
>   ARM: gic: add OF based initialization
> 
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++
>  arch/arm/common/gic.c                         |   57 +++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++
>  drivers/of/irq.c                              |   96 +++++++++++++++++++++++++
>  include/linux/irqdomain.h                     |    1 +
>  include/linux/of_irq.h                        |    1 +
>  kernel/irq/irqdomain.c                        |    2 +-
>  7 files changed, 214 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt

On imx6q:

Tested-by: Shawn Guo <shawn.guo@linaro.org>

-- 
Regards,
Shawn

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Benoit,

On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
> On 9/15/2011 3:11 PM, Rob Herring wrote:
>> Benoit,
>>
>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>> Hi Rob,
>>>
>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>> Hi Rob,
>>>>
>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>
>>>>> This adds gic initialization using device tree data. The
>>>>> initialization
>>>>> functions are intended to be called by a generic OF interrupt
>>>>> controller parsing function once the right pieces are in place.
>>>>>
>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>> the cpu
>>>>> mask the PPI is assigned to.
>>>>>
>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>> ++++++++++++++++++++++++
>>>>>    arch/arm/common/gic.c                         |   55
>>>>> +++++++++++++++++++++++--
>>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> [...]
>>>>
>>>>
>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>> index d1ccc72..14de380 100644
>>>>> --- a/arch/arm/common/gic.c
>>>>> +++ b/arch/arm/common/gic.c
>>>>
>>>> [...]
>>>>
>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>> *parent)
>>>>> +{
>>>>> +       void __iomem *cpu_base;
>>>>> +       void __iomem *dist_base;
>>>>> +       int irq;
>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>> +
>>>>> +       if (WARN_ON(!node))
>>>>> +               return;
>>>>> +
>>>>> +       dist_base = of_iomap(node, 0);
>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>> +
>>>>> +       cpu_base = of_iomap(node, 1);
>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>> +
>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>> numa_node_id());
>>>>
>>>> For exynos4, all the interrupts originating from GIC are statically
>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>> start from 64). In the above code, since irq_base would be 0 for
>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>> previous version of the patch, you have given a option to the platform
>>>> code to choose the offset. Could that option be added to this series
>>>> also. Or a provision to use platform specific translate function
>>>> instead of the irq_domain_simple translator.
>>>
>>> I have another concern on a similar topic.
>>>
>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>> 32. Only the internal PPI are between 0 and 31.
>>>
>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>
>> Those defines will not be used in the DT case. So the question is
>> whether to add 32 or not in the DT. Since we have just a single node and
>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>> agreement.
> 
> This is a agreement inside the MPUSS, but not outside.
> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
> with that today.
> 
>>> but I'm assuming that this offset calculation should be done thanks to a
>>> dedicated irq domain for the SPI.
>>> The real HW physical number start at 0, and thus this is that value that
>>> should be in the irq binding of the device.
>>>
>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>> case, but it looks like the PPI/SPI offset is always 32.
>>>
>>
>> That offset of SPIs is always there. If you have a GIC as a secondary
>> controller, It will have 32 reserved interrupts and the register layout
>> is exactly the same as a cpu's GIC.
> 
> Yep, but that's the GIC view and not the SoC one. My concern is to have
> to tweak the HW number provided by the HW spec in order to add that offset.
> If you look at SoC level, the MPUSS is just an IP that can be
> potentially replaced by other one that will not have a GIC. In that case
> you will not change the IRQ mapping at SoC level.
> For example if you replace the Dual-cortexA9 by a single CortexA8, then
> all the interrupts will have to be shifted by 32 just because the MPU
> subsystem is different.
> 

Is that a realistic case? That would be a new chip and new device tree.
You could argue that the whole peripheral subsystem DT could be reused
and the numbering needs to be the same. However, there's one thing that
would prevent that. The number of interrupt cells is defined by the
controller binding. So you have to change the peripheral nodes anyway.

It's good that OMAP is trying to standardize the peripheral layout, but
in my experience that's not something you can rely on.

At some point the interrupt numbering is going to differ from the h/w
documentation. If it's not in the DT, then it will be in linux. Right
now its just offset of 32, but if irqdescs get assigned on demand as PPC
is doing, then there will be no relationship to the documentation.

> Since that offset is dependent of the GIC internals and is not exposed
> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
> spec is exposing exactly that.
> 
>> Since the idea of splitting PPIs for each core out to a flattened linux
>> irq map has been abandoned, I see no reason to have more than 1 domain
>> with a simple linear translation. Ultimately, domains will do dynamic
>> irqdesc allocation and the translation within the gic will be completely
>> dynamic.
> 
> I think the only reason to do that is to separate internal MPU
> interrupts with the external ones that should not have a clue about the
> GIC.

I see 2 options (besides leaving it as is):

- Revert back to my previous binding where PPIs are a sub-node and a
different interrupt parent.

- Use the current binding, but allow SPIs to start at 0. We can still
distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
SPI. If there was ever a reason to have a cpu mask for an SPI, you would
not be able to with this scheme.

Either way you will still have the above issue with the cell size changing.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Benoit,

On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
> On 9/15/2011 3:11 PM, Rob Herring wrote:
>> Benoit,
>>
>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>> Hi Rob,
>>>
>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>> Hi Rob,
>>>>
>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>
>>>>> This adds gic initialization using device tree data. The
>>>>> initialization
>>>>> functions are intended to be called by a generic OF interrupt
>>>>> controller parsing function once the right pieces are in place.
>>>>>
>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>> the cpu
>>>>> mask the PPI is assigned to.
>>>>>
>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>> ++++++++++++++++++++++++
>>>>>    arch/arm/common/gic.c                         |   55
>>>>> +++++++++++++++++++++++--
>>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> [...]
>>>>
>>>>
>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>> index d1ccc72..14de380 100644
>>>>> --- a/arch/arm/common/gic.c
>>>>> +++ b/arch/arm/common/gic.c
>>>>
>>>> [...]
>>>>
>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>> *parent)
>>>>> +{
>>>>> +       void __iomem *cpu_base;
>>>>> +       void __iomem *dist_base;
>>>>> +       int irq;
>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>> +
>>>>> +       if (WARN_ON(!node))
>>>>> +               return;
>>>>> +
>>>>> +       dist_base = of_iomap(node, 0);
>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>> +
>>>>> +       cpu_base = of_iomap(node, 1);
>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>> +
>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>> numa_node_id());
>>>>
>>>> For exynos4, all the interrupts originating from GIC are statically
>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>> start from 64). In the above code, since irq_base would be 0 for
>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>> previous version of the patch, you have given a option to the platform
>>>> code to choose the offset. Could that option be added to this series
>>>> also. Or a provision to use platform specific translate function
>>>> instead of the irq_domain_simple translator.
>>>
>>> I have another concern on a similar topic.
>>>
>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>> 32. Only the internal PPI are between 0 and 31.
>>>
>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>
>> Those defines will not be used in the DT case. So the question is
>> whether to add 32 or not in the DT. Since we have just a single node and
>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>> agreement.
> 
> This is a agreement inside the MPUSS, but not outside.
> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
> with that today.
> 
>>> but I'm assuming that this offset calculation should be done thanks to a
>>> dedicated irq domain for the SPI.
>>> The real HW physical number start at 0, and thus this is that value that
>>> should be in the irq binding of the device.
>>>
>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>> case, but it looks like the PPI/SPI offset is always 32.
>>>
>>
>> That offset of SPIs is always there. If you have a GIC as a secondary
>> controller, It will have 32 reserved interrupts and the register layout
>> is exactly the same as a cpu's GIC.
> 
> Yep, but that's the GIC view and not the SoC one. My concern is to have
> to tweak the HW number provided by the HW spec in order to add that offset.
> If you look at SoC level, the MPUSS is just an IP that can be
> potentially replaced by other one that will not have a GIC. In that case
> you will not change the IRQ mapping at SoC level.
> For example if you replace the Dual-cortexA9 by a single CortexA8, then
> all the interrupts will have to be shifted by 32 just because the MPU
> subsystem is different.
> 

Is that a realistic case? That would be a new chip and new device tree.
You could argue that the whole peripheral subsystem DT could be reused
and the numbering needs to be the same. However, there's one thing that
would prevent that. The number of interrupt cells is defined by the
controller binding. So you have to change the peripheral nodes anyway.

It's good that OMAP is trying to standardize the peripheral layout, but
in my experience that's not something you can rely on.

At some point the interrupt numbering is going to differ from the h/w
documentation. If it's not in the DT, then it will be in linux. Right
now its just offset of 32, but if irqdescs get assigned on demand as PPC
is doing, then there will be no relationship to the documentation.

> Since that offset is dependent of the GIC internals and is not exposed
> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
> spec is exposing exactly that.
> 
>> Since the idea of splitting PPIs for each core out to a flattened linux
>> irq map has been abandoned, I see no reason to have more than 1 domain
>> with a simple linear translation. Ultimately, domains will do dynamic
>> irqdesc allocation and the translation within the gic will be completely
>> dynamic.
> 
> I think the only reason to do that is to separate internal MPU
> interrupts with the external ones that should not have a clue about the
> GIC.

I see 2 options (besides leaving it as is):

- Revert back to my previous binding where PPIs are a sub-node and a
different interrupt parent.

- Use the current binding, but allow SPIs to start at 0. We can still
distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
SPI. If there was ever a reason to have a cpu mask for an SPI, you would
not be able to with this scheme.

Either way you will still have the above issue with the cell size changing.

Rob

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

Benoit,

On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
> On 9/15/2011 3:11 PM, Rob Herring wrote:
>> Benoit,
>>
>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>> Hi Rob,
>>>
>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>> Hi Rob,
>>>>
>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>
>>>>> This adds gic initialization using device tree data. The
>>>>> initialization
>>>>> functions are intended to be called by a generic OF interrupt
>>>>> controller parsing function once the right pieces are in place.
>>>>>
>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>> the cpu
>>>>> mask the PPI is assigned to.
>>>>>
>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>> ---
>>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>> ++++++++++++++++++++++++
>>>>>    arch/arm/common/gic.c                         |   55
>>>>> +++++++++++++++++++++++--
>>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> [...]
>>>>
>>>>
>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>> index d1ccc72..14de380 100644
>>>>> --- a/arch/arm/common/gic.c
>>>>> +++ b/arch/arm/common/gic.c
>>>>
>>>> [...]
>>>>
>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>> *parent)
>>>>> +{
>>>>> +       void __iomem *cpu_base;
>>>>> +       void __iomem *dist_base;
>>>>> +       int irq;
>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>> +
>>>>> +       if (WARN_ON(!node))
>>>>> +               return;
>>>>> +
>>>>> +       dist_base = of_iomap(node, 0);
>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>> +
>>>>> +       cpu_base = of_iomap(node, 1);
>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>> +
>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>> numa_node_id());
>>>>
>>>> For exynos4, all the interrupts originating from GIC are statically
>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>> start from 64). In the above code, since irq_base would be 0 for
>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>> previous version of the patch, you have given a option to the platform
>>>> code to choose the offset. Could that option be added to this series
>>>> also. Or a provision to use platform specific translate function
>>>> instead of the irq_domain_simple translator.
>>>
>>> I have another concern on a similar topic.
>>>
>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>> 32. Only the internal PPI are between 0 and 31.
>>>
>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>
>> Those defines will not be used in the DT case. So the question is
>> whether to add 32 or not in the DT. Since we have just a single node and
>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>> agreement.
> 
> This is a agreement inside the MPUSS, but not outside.
> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
> with that today.
> 
>>> but I'm assuming that this offset calculation should be done thanks to a
>>> dedicated irq domain for the SPI.
>>> The real HW physical number start at 0, and thus this is that value that
>>> should be in the irq binding of the device.
>>>
>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>> case, but it looks like the PPI/SPI offset is always 32.
>>>
>>
>> That offset of SPIs is always there. If you have a GIC as a secondary
>> controller, It will have 32 reserved interrupts and the register layout
>> is exactly the same as a cpu's GIC.
> 
> Yep, but that's the GIC view and not the SoC one. My concern is to have
> to tweak the HW number provided by the HW spec in order to add that offset.
> If you look at SoC level, the MPUSS is just an IP that can be
> potentially replaced by other one that will not have a GIC. In that case
> you will not change the IRQ mapping at SoC level.
> For example if you replace the Dual-cortexA9 by a single CortexA8, then
> all the interrupts will have to be shifted by 32 just because the MPU
> subsystem is different.
> 

Is that a realistic case? That would be a new chip and new device tree.
You could argue that the whole peripheral subsystem DT could be reused
and the numbering needs to be the same. However, there's one thing that
would prevent that. The number of interrupt cells is defined by the
controller binding. So you have to change the peripheral nodes anyway.

It's good that OMAP is trying to standardize the peripheral layout, but
in my experience that's not something you can rely on.

At some point the interrupt numbering is going to differ from the h/w
documentation. If it's not in the DT, then it will be in linux. Right
now its just offset of 32, but if irqdescs get assigned on demand as PPC
is doing, then there will be no relationship to the documentation.

> Since that offset is dependent of the GIC internals and is not exposed
> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
> spec is exposing exactly that.
> 
>> Since the idea of splitting PPIs for each core out to a flattened linux
>> irq map has been abandoned, I see no reason to have more than 1 domain
>> with a simple linear translation. Ultimately, domains will do dynamic
>> irqdesc allocation and the translation within the gic will be completely
>> dynamic.
> 
> I think the only reason to do that is to separate internal MPU
> interrupts with the external ones that should not have a clue about the
> GIC.

I see 2 options (besides leaving it as is):

- Revert back to my previous binding where PPIs are a sub-node and a
different interrupt parent.

- Use the current binding, but allow SPIs to start at 0. We can still
distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
SPI. If there was ever a reason to have a cpu mask for an SPI, you would
not be able to with this scheme.

Either way you will still have the above issue with the cell size changing.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Rob,

On 15 September 2011 18:24, Rob Herring <robherring2@gmail.com> wrote:
> On 09/15/2011 02:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>>> +{
>>> +       void __iomem *cpu_base;
>>> +       void __iomem *dist_base;
>>> +       int irq;
>>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>>> +
>>> +       if (WARN_ON(!node))
>>> +               return;
>>> +
>>> +       dist_base = of_iomap(node, 0);
>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> +       cpu_base = of_iomap(node, 1);
>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
>>
>
> So I guess you have the A9 external nIRQ hooked up to another
> controller? Why can't the 0-31 interrupts get mapped to after the gic
> interrupts? Ultimately we want h/w irq numbers completely decoupled from
> linux irq numbers. So you will want to put that controller in devicetree
> and have an DT init function for it as well.

There are chained interrupt handlers mapped in between linux irq
number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
= 32). The interrupt chaining for the interrupts mapped between 0 to
31 seems unnecessary though. I will try removing them and check.

>
> In anycase, there's a simple solution. You just need a call to
> irq_alloc_descs to reserve the first 32 interrupts before calling
> of_irq_init.
>
> Rob
>

Thanks for your comments.

Regards,
Thomas.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Rob,

On 15 September 2011 18:24, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 09/15/2011 02:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>> ---
>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>  3 files changed, 114 insertions(+), 4 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>>> +{
>>> +       void __iomem *cpu_base;
>>> +       void __iomem *dist_base;
>>> +       int irq;
>>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>>> +
>>> +       if (WARN_ON(!node))
>>> +               return;
>>> +
>>> +       dist_base = of_iomap(node, 0);
>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> +       cpu_base = of_iomap(node, 1);
>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
>>
>
> So I guess you have the A9 external nIRQ hooked up to another
> controller? Why can't the 0-31 interrupts get mapped to after the gic
> interrupts? Ultimately we want h/w irq numbers completely decoupled from
> linux irq numbers. So you will want to put that controller in devicetree
> and have an DT init function for it as well.

There are chained interrupt handlers mapped in between linux irq
number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
= 32). The interrupt chaining for the interrupts mapped between 0 to
31 seems unnecessary though. I will try removing them and check.

>
> In anycase, there's a simple solution. You just need a call to
> irq_alloc_descs to reserve the first 32 interrupts before calling
> of_irq_init.
>
> Rob
>

Thanks for your comments.

Regards,
Thomas.

[PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Rob,

On 15 September 2011 18:24, Rob Herring <robherring2@gmail.com> wrote:
> On 09/15/2011 02:55 AM, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 14 September 2011 22:01, Rob Herring <robherring2@gmail.com> wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> This adds gic initialization using device tree data. The initialization
>>> functions are intended to be called by a generic OF interrupt
>>> controller parsing function once the right pieces are in place.
>>>
>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>> mask the PPI is assigned to.
>>>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> ---
>>> ?Documentation/devicetree/bindings/arm/gic.txt | ? 53 ++++++++++++++++++++++++
>>> ?arch/arm/common/gic.c ? ? ? ? ? ? ? ? ? ? ? ? | ? 55 +++++++++++++++++++++++--
>>> ?arch/arm/include/asm/hardware/gic.h ? ? ? ? ? | ? 10 +++++
>>> ?3 files changed, 114 insertions(+), 4 deletions(-)
>>> ?create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>
>> [...]
>>
>>
>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>> index d1ccc72..14de380 100644
>>> --- a/arch/arm/common/gic.c
>>> +++ b/arch/arm/common/gic.c
>>
>> [...]
>>
>>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>>> +{
>>> + ? ? ? void __iomem *cpu_base;
>>> + ? ? ? void __iomem *dist_base;
>>> + ? ? ? int irq;
>>> + ? ? ? struct irq_domain *domain = &gic_data[gic_cnt].domain;
>>> +
>>> + ? ? ? if (WARN_ON(!node))
>>> + ? ? ? ? ? ? ? return;
>>> +
>>> + ? ? ? dist_base = of_iomap(node, 0);
>>> + ? ? ? WARN(!dist_base, "unable to map gic dist registers\n");
>>> +
>>> + ? ? ? cpu_base = of_iomap(node, 1);
>>> + ? ? ? WARN(!cpu_base, "unable to map gic cpu registers\n");
>>> +
>>> + ? ? ? domain->nr_irq = gic_irq_count(dist_base);
>>> + ? ? ? domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>>
>> For exynos4, all the interrupts originating from GIC are statically
>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> start from 64). In the above code, since irq_base would be 0 for
>> exynos4, the interrupt mapping is not working correctly. In your
>> previous version of the patch, you have given a option to the platform
>> code to choose the offset. Could that option be added to this series
>> also. Or a provision to use platform specific translate function
>> instead of the irq_domain_simple translator.
>>
>
> So I guess you have the A9 external nIRQ hooked up to another
> controller? Why can't the 0-31 interrupts get mapped to after the gic
> interrupts? Ultimately we want h/w irq numbers completely decoupled from
> linux irq numbers. So you will want to put that controller in devicetree
> and have an DT init function for it as well.

There are chained interrupt handlers mapped in between linux irq
number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
= 32). The interrupt chaining for the interrupts mapped between 0 to
31 seems unnecessary though. I will try removing them and check.

>
> In anycase, there's a simple solution. You just need a call to
> irq_alloc_descs to reserve the first 32 interrupts before calling
> of_irq_init.
>
> Rob
>

Thanks for your comments.

Regards,
Thomas.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Dave Martin]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> >Hi Rob,
> >
> >On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
> >>From: Rob Herring<rob.herring@calxeda.com>
> >>
> >>This adds gic initialization using device tree data. The initialization
> >>functions are intended to be called by a generic OF interrupt
> >>controller parsing function once the right pieces are in place.
> >>
> >>PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>mask the PPI is assigned to.
> >>
> >>Signed-off-by: Rob Herring<rob.herring@calxeda.com>
> >>---
> >>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >
> >[...]
> >
> >
> >>diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >>index d1ccc72..14de380 100644
> >>--- a/arch/arm/common/gic.c
> >>+++ b/arch/arm/common/gic.c
> >
> >[...]
> >
> >>+void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>+{
> >>+       void __iomem *cpu_base;
> >>+       void __iomem *dist_base;
> >>+       int irq;
> >>+       struct irq_domain *domain =&gic_data[gic_cnt].domain;
> >>+
> >>+       if (WARN_ON(!node))
> >>+               return;
> >>+
> >>+       dist_base = of_iomap(node, 0);
> >>+       WARN(!dist_base, "unable to map gic dist registers\n");
> >>+
> >>+       cpu_base = of_iomap(node, 1);
> >>+       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>+
> >>+       domain->nr_irq = gic_irq_count(dist_base);
> >>+       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >
> >For exynos4, all the interrupts originating from GIC are statically
> >mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >start from 64). In the above code, since irq_base would be 0 for
> >exynos4, the interrupt mapping is not working correctly. In your
> >previous version of the patch, you have given a option to the platform
> >code to choose the offset. Could that option be added to this series
> >also. Or a provision to use platform specific translate function
> >instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
> of 32. Only the internal PPI are between 0 and 31.

On a similar theme, on Versatile express the motherboard and core-tiles
are independent things, and the GIC lives on the core-tile (the motherboard
has no interrupt controller of its owh).

This means that the mapping of motherboard peripheral interrupts onto
GIC inputs is dependent on the coretile.

Since the DT is supposed to be descrbing the hardware in a componentised
way, the motherboard description should be independent of the core-tile
description except for describing the interface between the two.


For now, we express the mapping by putting an interrupt-map in the
core-tile DT, but this feels inelegant as well as wasteful -- expressing
"+ 32" using a table which is about 1K in size and duplicates that
information 43 times.

Using a dedicated irq domain or a fake interrupt controller node to
encapsulate the motherboard interrupts feels like a cleaner approach,
but for now I'm not clear on the best way to do it.

Cheers
---Dave

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Dave Martin]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> >Hi Rob,
> >
> >On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
> >>From: Rob Herring<rob.herring@calxeda.com>
> >>
> >>This adds gic initialization using device tree data. The initialization
> >>functions are intended to be called by a generic OF interrupt
> >>controller parsing function once the right pieces are in place.
> >>
> >>PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>mask the PPI is assigned to.
> >>
> >>Signed-off-by: Rob Herring<rob.herring@calxeda.com>
> >>---
> >>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >
> >[...]
> >
> >
> >>diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >>index d1ccc72..14de380 100644
> >>--- a/arch/arm/common/gic.c
> >>+++ b/arch/arm/common/gic.c
> >
> >[...]
> >
> >>+void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>+{
> >>+       void __iomem *cpu_base;
> >>+       void __iomem *dist_base;
> >>+       int irq;
> >>+       struct irq_domain *domain =&gic_data[gic_cnt].domain;
> >>+
> >>+       if (WARN_ON(!node))
> >>+               return;
> >>+
> >>+       dist_base = of_iomap(node, 0);
> >>+       WARN(!dist_base, "unable to map gic dist registers\n");
> >>+
> >>+       cpu_base = of_iomap(node, 1);
> >>+       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>+
> >>+       domain->nr_irq = gic_irq_count(dist_base);
> >>+       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >
> >For exynos4, all the interrupts originating from GIC are statically
> >mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >start from 64). In the above code, since irq_base would be 0 for
> >exynos4, the interrupt mapping is not working correctly. In your
> >previous version of the patch, you have given a option to the platform
> >code to choose the offset. Could that option be added to this series
> >also. Or a provision to use platform specific translate function
> >instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
> of 32. Only the internal PPI are between 0 and 31.

On a similar theme, on Versatile express the motherboard and core-tiles
are independent things, and the GIC lives on the core-tile (the motherboard
has no interrupt controller of its owh).

This means that the mapping of motherboard peripheral interrupts onto
GIC inputs is dependent on the coretile.

Since the DT is supposed to be descrbing the hardware in a componentised
way, the motherboard description should be independent of the core-tile
description except for describing the interface between the two.


For now, we express the mapping by putting an interrupt-map in the
core-tile DT, but this feels inelegant as well as wasteful -- expressing
"+ 32" using a table which is about 1K in size and duplicates that
information 43 times.

Using a dedicated irq domain or a fake interrupt controller node to
encapsulate the motherboard interrupts feels like a cleaner approach,
but for now I'm not clear on the best way to do it.

Cheers
---Dave

[PATCH 5/5] ARM: gic: add OF based initialization

[Dave Martin]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> >Hi Rob,
> >
> >On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
> >>From: Rob Herring<rob.herring@calxeda.com>
> >>
> >>This adds gic initialization using device tree data. The initialization
> >>functions are intended to be called by a generic OF interrupt
> >>controller parsing function once the right pieces are in place.
> >>
> >>PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>mask the PPI is assigned to.
> >>
> >>Signed-off-by: Rob Herring<rob.herring@calxeda.com>
> >>---
> >>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >
> >[...]
> >
> >
> >>diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >>index d1ccc72..14de380 100644
> >>--- a/arch/arm/common/gic.c
> >>+++ b/arch/arm/common/gic.c
> >
> >[...]
> >
> >>+void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>+{
> >>+       void __iomem *cpu_base;
> >>+       void __iomem *dist_base;
> >>+       int irq;
> >>+       struct irq_domain *domain =&gic_data[gic_cnt].domain;
> >>+
> >>+       if (WARN_ON(!node))
> >>+               return;
> >>+
> >>+       dist_base = of_iomap(node, 0);
> >>+       WARN(!dist_base, "unable to map gic dist registers\n");
> >>+
> >>+       cpu_base = of_iomap(node, 1);
> >>+       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>+
> >>+       domain->nr_irq = gic_irq_count(dist_base);
> >>+       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >
> >For exynos4, all the interrupts originating from GIC are statically
> >mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >start from 64). In the above code, since irq_base would be 0 for
> >exynos4, the interrupt mapping is not working correctly. In your
> >previous version of the patch, you have given a option to the platform
> >code to choose the offset. Could that option be added to this series
> >also. Or a provision to use platform specific translate function
> >instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
> of 32. Only the internal PPI are between 0 and 31.

On a similar theme, on Versatile express the motherboard and core-tiles
are independent things, and the GIC lives on the core-tile (the motherboard
has no interrupt controller of its owh).

This means that the mapping of motherboard peripheral interrupts onto
GIC inputs is dependent on the coretile.

Since the DT is supposed to be descrbing the hardware in a componentised
way, the motherboard description should be independent of the core-tile
description except for describing the interface between the two.


For now, we express the mapping by putting an interrupt-map in the
core-tile DT, but this feels inelegant as well as wasteful -- expressing
"+ 32" using a table which is about 1K in size and duplicates that
information 43 times.

Using a dedicated irq domain or a fake interrupt controller node to
encapsulate the motherboard interrupts feels like a cleaner approach,
but for now I'm not clear on the best way to do it.

Cheers
---Dave

Re: [PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Grant Likely]

On Wed, Sep 14, 2011 at 06:44:50PM +0200, Thomas Gleixner wrote:
> On Wed, 14 Sep 2011, Rob Herring wrote:
> 
> > From: Rob Herring <rob.herring@calxeda.com>
> > 
> > irq_data will normally exist, so the domain was prevented from being set.
> > The simple domain code did not hit this as nr_irq is always 0.
> > 
> > Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> 
> I take this and 1/5 through irq/urgent

Thanks Thomas.

g.

> 
> Thanks,
> 
> 	tglx
> 
> > ---
> >  kernel/irq/irqdomain.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > index d5828da..84f4110 100644
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
> >  	 */
> >  	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
> >  		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> > -		if (d || d->domain) {
> > +		if (d && d->domain) {
> >  			/* things are broken; just report, don't clean up */
> >  			WARN(1, "error: irq_desc already assigned to a domain");
> >  			return;
> > -- 
> > 1.7.5.4
> > 
> > 

Re: [PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Grant Likely]

On Wed, Sep 14, 2011 at 06:44:50PM +0200, Thomas Gleixner wrote:
> On Wed, 14 Sep 2011, Rob Herring wrote:
> 
> > From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> > 
> > irq_data will normally exist, so the domain was prevented from being set.
> > The simple domain code did not hit this as nr_irq is always 0.
> > 
> > Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> > Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> > Cc: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
> 
> I take this and 1/5 through irq/urgent

Thanks Thomas.

g.

> 
> Thanks,
> 
> 	tglx
> 
> > ---
> >  kernel/irq/irqdomain.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > index d5828da..84f4110 100644
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
> >  	 */
> >  	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
> >  		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> > -		if (d || d->domain) {
> > +		if (d && d->domain) {
> >  			/* things are broken; just report, don't clean up */
> >  			WARN(1, "error: irq_desc already assigned to a domain");
> >  			return;
> > -- 
> > 1.7.5.4
> > 
> > 

[PATCH 2/5] irq: fix existing domain check in irq_domain_add

[Grant Likely]

On Wed, Sep 14, 2011 at 06:44:50PM +0200, Thomas Gleixner wrote:
> On Wed, 14 Sep 2011, Rob Herring wrote:
> 
> > From: Rob Herring <rob.herring@calxeda.com>
> > 
> > irq_data will normally exist, so the domain was prevented from being set.
> > The simple domain code did not hit this as nr_irq is always 0.
> > 
> > Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> 
> I take this and 1/5 through irq/urgent

Thanks Thomas.

g.

> 
> Thanks,
> 
> 	tglx
> 
> > ---
> >  kernel/irq/irqdomain.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > index d5828da..84f4110 100644
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -29,7 +29,7 @@ void irq_domain_add(struct irq_domain *domain)
> >  	 */
> >  	for (hwirq = 0; hwirq < domain->nr_irq; hwirq++) {
> >  		d = irq_get_irq_data(irq_domain_to_irq(domain, hwirq));
> > -		if (d || d->domain) {
> > +		if (d && d->domain) {
> >  			/* things are broken; just report, don't clean up */
> >  			WARN(1, "error: irq_desc already assigned to a domain");
> >  			return;
> > -- 
> > 1.7.5.4
> > 
> > 

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
> 
> Based on initial pseudo code from Grant Likely.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
>  drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_irq.h |    1 +
>  2 files changed, 97 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 9f689f1..a0cd7e8 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -19,10 +19,13 @@
>   */
>  
>  #include <linux/errno.h>
> +#include <linux/list.h>
> +#include <linux/list_sort.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/string.h>
> +#include <linux/slab.h>
>  
>  /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
>  #ifndef NO_IRQ
> @@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>  
>  	return i;
>  }
> +
> +struct intc_desc {
> +	struct list_head	list;
> +	struct device_node	*dev;
> +	struct device_node	*parent;
> +};
> +
> +typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
> +
> +static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
> +				    struct list_head *b)
> +{
> +	const struct intc_desc *da = list_entry(a, typeof(*da), list);
> +	const struct intc_desc *db = list_entry(b, typeof(*db), list);
> +
> +	/* same parent, so order doesn't matter */
> +	if (da->parent == db->parent)
> +		return 0;
> +
> +	/* NULL parent comes first */
> +	if (!da->parent && db->parent)
> +		return -1;
> +	if (!db->parent && da->parent)
> +		return 1;
> +
> +	/* parent node must be before child node */
> +	if (da->dev == db->parent)
> +		return -1;
> +	if (db->dev == da->parent)
> +		return 1;

Does sort_list work for relationships 4 or more levels deep?  ie. if
there was a relationship of A <- B <- C <- D, then B compared with D
would return 0 from this function which could potentially result in an
incorrectly ordered list.

The other option for implementing this would be to take the probe
deferral approach and not try to sort the list, but instead allow
probe functions to fail & request retry if the parent hasn't yet been
probed.  I haven't thought enough about it though to say which would
be the best approach.

> +
> +	return 0;
> +}
> +
> +/**
> + * of_irq_init - Scan the device tree for matching interrupt controllers and
> + * call their initialization functions in order with parents first.
> + * @matches: 0 terminated array of nodes to match and initialization function
> + * to call on match
> + */
> +void __init of_irq_init(const struct of_device_id *matches)
> +{
> +	struct device_node *np;
> +	const struct of_device_id *match;
> +	struct intc_desc *desc;
> +	struct intc_desc *temp_desc;
> +	struct list_head intc_desc_list;
> +
> +	INIT_LIST_HEAD(&intc_desc_list);
> +
> +	for_each_matching_node(np, matches) {
> +		if (!of_find_property(np, "interrupt-controller", NULL))
> +			continue;
> +		/* Here, we allocate and populate an intc_desc with the node
> +		* pointer, interrupt-parent device_node etc. */
> +		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> +		if (!desc) {
> +			WARN_ON(1);
> +			goto err;
> +		}
> +		desc->dev = np;
> +		desc->parent = of_irq_find_parent(np);
> +		list_add(&desc->list, &intc_desc_list);
> +	}
> +	if (list_empty(&intc_desc_list))
> +		return;
> +
> +	/*
> +	 * The root irq controller is the one without an interrupt-parent.
> +	 * That one goes first, followed by the controllers that reference it,
> +	 * followed by the ones that reference the 2nd level controllers, etc
> +	 */

I don't believe that this actually turns out to be true (and yes I
know it is how I originally described it).  :-)  When the
interrupt-parent property is at the root of the tree, then the root
interrupt controller may very well inherit itself as it's interrupt
parent, and of_irq_find_parent() will still return a value.  This
should probably be considered a bug in of_irq_find_parent(), and it
should return NULL if the parent is itself.

of_irq_find_parent should probably be implemented thusly (completely
untested); although the only functional change is the line:
	return (p == child) ? NULL : p;

/**
 * of_irq_find_parent - Given a device node, find its interrupt parent node
 * @child: pointer to device node
 *
 * Returns a pointer to the interrupt parent node, or NULL if the
 * interrupt parent could not be determined.
 */
struct device_node *of_irq_find_parent(struct device_node *child)
{
	struct device_node *p, *c = child;
	const __be32 *parp;

	if (!of_node_get(c))
		return NULL;

	do {
		p = of_parse_phandle(c, "interrupt-parent", 0);

		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
		    of_find_property(c, "interrupt-parent", NULL))
			p = of_node_get(of_irq_dflt_pic);

		if (!p)
			p = of_get_parent(c);

		of_node_put(c);
		c = p;
	} while (p && !of_find_property(p, "#interrupt-cells", NULL));

	return (p == child) ? NULL : p;
}


> +	list_sort(NULL, &intc_desc_list, irq_cmp_intc_desc);
> +
> +	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> +		match = of_match_node(matches, desc->dev);
> +		if (match && match->data) {
> +			irq_init_cb_t irq_init_cb = match->data;
> +			pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> +				 match->compatible, desc->dev, desc->parent);
> +			irq_init_cb(desc->dev, desc->parent);
> +		}
> +		list_del(&desc->list);
> +		kfree(desc);
> +	}
> +	return;
> +
> +err:
> +	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> +		list_del(&desc->list);
> +		kfree(desc);
> +	}
> +}

Overall, I'm pretty happy with how this is looking.  Great job!

g.

> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index cd2e61c..032d76c 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
>  		struct resource *res, int nr_irqs);
>  extern struct device_node *of_irq_find_parent(struct device_node *child);
>  
> +extern void of_irq_init(const struct of_device_id *matches);
>  
>  #endif /* CONFIG_OF_IRQ */
>  #endif /* CONFIG_OF */
> -- 
> 1.7.5.4
> 

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
> 
> Based on initial pseudo code from Grant Likely.
> 
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> ---
>  drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_irq.h |    1 +
>  2 files changed, 97 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 9f689f1..a0cd7e8 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -19,10 +19,13 @@
>   */
>  
>  #include <linux/errno.h>
> +#include <linux/list.h>
> +#include <linux/list_sort.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/string.h>
> +#include <linux/slab.h>
>  
>  /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
>  #ifndef NO_IRQ
> @@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>  
>  	return i;
>  }
> +
> +struct intc_desc {
> +	struct list_head	list;
> +	struct device_node	*dev;
> +	struct device_node	*parent;
> +};
> +
> +typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
> +
> +static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
> +				    struct list_head *b)
> +{
> +	const struct intc_desc *da = list_entry(a, typeof(*da), list);
> +	const struct intc_desc *db = list_entry(b, typeof(*db), list);
> +
> +	/* same parent, so order doesn't matter */
> +	if (da->parent == db->parent)
> +		return 0;
> +
> +	/* NULL parent comes first */
> +	if (!da->parent && db->parent)
> +		return -1;
> +	if (!db->parent && da->parent)
> +		return 1;
> +
> +	/* parent node must be before child node */
> +	if (da->dev == db->parent)
> +		return -1;
> +	if (db->dev == da->parent)
> +		return 1;

Does sort_list work for relationships 4 or more levels deep?  ie. if
there was a relationship of A <- B <- C <- D, then B compared with D
would return 0 from this function which could potentially result in an
incorrectly ordered list.

The other option for implementing this would be to take the probe
deferral approach and not try to sort the list, but instead allow
probe functions to fail & request retry if the parent hasn't yet been
probed.  I haven't thought enough about it though to say which would
be the best approach.

> +
> +	return 0;
> +}
> +
> +/**
> + * of_irq_init - Scan the device tree for matching interrupt controllers and
> + * call their initialization functions in order with parents first.
> + * @matches: 0 terminated array of nodes to match and initialization function
> + * to call on match
> + */
> +void __init of_irq_init(const struct of_device_id *matches)
> +{
> +	struct device_node *np;
> +	const struct of_device_id *match;
> +	struct intc_desc *desc;
> +	struct intc_desc *temp_desc;
> +	struct list_head intc_desc_list;
> +
> +	INIT_LIST_HEAD(&intc_desc_list);
> +
> +	for_each_matching_node(np, matches) {
> +		if (!of_find_property(np, "interrupt-controller", NULL))
> +			continue;
> +		/* Here, we allocate and populate an intc_desc with the node
> +		* pointer, interrupt-parent device_node etc. */
> +		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> +		if (!desc) {
> +			WARN_ON(1);
> +			goto err;
> +		}
> +		desc->dev = np;
> +		desc->parent = of_irq_find_parent(np);
> +		list_add(&desc->list, &intc_desc_list);
> +	}
> +	if (list_empty(&intc_desc_list))
> +		return;
> +
> +	/*
> +	 * The root irq controller is the one without an interrupt-parent.
> +	 * That one goes first, followed by the controllers that reference it,
> +	 * followed by the ones that reference the 2nd level controllers, etc
> +	 */

I don't believe that this actually turns out to be true (and yes I
know it is how I originally described it).  :-)  When the
interrupt-parent property is at the root of the tree, then the root
interrupt controller may very well inherit itself as it's interrupt
parent, and of_irq_find_parent() will still return a value.  This
should probably be considered a bug in of_irq_find_parent(), and it
should return NULL if the parent is itself.

of_irq_find_parent should probably be implemented thusly (completely
untested); although the only functional change is the line:
	return (p == child) ? NULL : p;

/**
 * of_irq_find_parent - Given a device node, find its interrupt parent node
 * @child: pointer to device node
 *
 * Returns a pointer to the interrupt parent node, or NULL if the
 * interrupt parent could not be determined.
 */
struct device_node *of_irq_find_parent(struct device_node *child)
{
	struct device_node *p, *c = child;
	const __be32 *parp;

	if (!of_node_get(c))
		return NULL;

	do {
		p = of_parse_phandle(c, "interrupt-parent", 0);

		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
		    of_find_property(c, "interrupt-parent", NULL))
			p = of_node_get(of_irq_dflt_pic);

		if (!p)
			p = of_get_parent(c);

		of_node_put(c);
		c = p;
	} while (p && !of_find_property(p, "#interrupt-cells", NULL));

	return (p == child) ? NULL : p;
}


> +	list_sort(NULL, &intc_desc_list, irq_cmp_intc_desc);
> +
> +	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> +		match = of_match_node(matches, desc->dev);
> +		if (match && match->data) {
> +			irq_init_cb_t irq_init_cb = match->data;
> +			pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> +				 match->compatible, desc->dev, desc->parent);
> +			irq_init_cb(desc->dev, desc->parent);
> +		}
> +		list_del(&desc->list);
> +		kfree(desc);
> +	}
> +	return;
> +
> +err:
> +	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> +		list_del(&desc->list);
> +		kfree(desc);
> +	}
> +}

Overall, I'm pretty happy with how this is looking.  Great job!

g.

> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index cd2e61c..032d76c 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
>  		struct resource *res, int nr_irqs);
>  extern struct device_node *of_irq_find_parent(struct device_node *child);
>  
> +extern void of_irq_init(const struct of_device_id *matches);
>  
>  #endif /* CONFIG_OF_IRQ */
>  #endif /* CONFIG_OF */
> -- 
> 1.7.5.4
> 

[PATCH 3/5] of/irq: introduce of_irq_init

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> of_irq_init will scan the devicetree for matching interrupt controller
> nodes. Then it calls an initialization function for each found controller
> in the proper order with parent nodes initialized before child nodes.
> 
> Based on initial pseudo code from Grant Likely.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
>  drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_irq.h |    1 +
>  2 files changed, 97 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 9f689f1..a0cd7e8 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -19,10 +19,13 @@
>   */
>  
>  #include <linux/errno.h>
> +#include <linux/list.h>
> +#include <linux/list_sort.h>
>  #include <linux/module.h>
>  #include <linux/of.h>
>  #include <linux/of_irq.h>
>  #include <linux/string.h>
> +#include <linux/slab.h>
>  
>  /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
>  #ifndef NO_IRQ
> @@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>  
>  	return i;
>  }
> +
> +struct intc_desc {
> +	struct list_head	list;
> +	struct device_node	*dev;
> +	struct device_node	*parent;
> +};
> +
> +typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
> +
> +static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
> +				    struct list_head *b)
> +{
> +	const struct intc_desc *da = list_entry(a, typeof(*da), list);
> +	const struct intc_desc *db = list_entry(b, typeof(*db), list);
> +
> +	/* same parent, so order doesn't matter */
> +	if (da->parent == db->parent)
> +		return 0;
> +
> +	/* NULL parent comes first */
> +	if (!da->parent && db->parent)
> +		return -1;
> +	if (!db->parent && da->parent)
> +		return 1;
> +
> +	/* parent node must be before child node */
> +	if (da->dev == db->parent)
> +		return -1;
> +	if (db->dev == da->parent)
> +		return 1;

Does sort_list work for relationships 4 or more levels deep?  ie. if
there was a relationship of A <- B <- C <- D, then B compared with D
would return 0 from this function which could potentially result in an
incorrectly ordered list.

The other option for implementing this would be to take the probe
deferral approach and not try to sort the list, but instead allow
probe functions to fail & request retry if the parent hasn't yet been
probed.  I haven't thought enough about it though to say which would
be the best approach.

> +
> +	return 0;
> +}
> +
> +/**
> + * of_irq_init - Scan the device tree for matching interrupt controllers and
> + * call their initialization functions in order with parents first.
> + * @matches: 0 terminated array of nodes to match and initialization function
> + * to call on match
> + */
> +void __init of_irq_init(const struct of_device_id *matches)
> +{
> +	struct device_node *np;
> +	const struct of_device_id *match;
> +	struct intc_desc *desc;
> +	struct intc_desc *temp_desc;
> +	struct list_head intc_desc_list;
> +
> +	INIT_LIST_HEAD(&intc_desc_list);
> +
> +	for_each_matching_node(np, matches) {
> +		if (!of_find_property(np, "interrupt-controller", NULL))
> +			continue;
> +		/* Here, we allocate and populate an intc_desc with the node
> +		* pointer, interrupt-parent device_node etc. */
> +		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
> +		if (!desc) {
> +			WARN_ON(1);
> +			goto err;
> +		}
> +		desc->dev = np;
> +		desc->parent = of_irq_find_parent(np);
> +		list_add(&desc->list, &intc_desc_list);
> +	}
> +	if (list_empty(&intc_desc_list))
> +		return;
> +
> +	/*
> +	 * The root irq controller is the one without an interrupt-parent.
> +	 * That one goes first, followed by the controllers that reference it,
> +	 * followed by the ones that reference the 2nd level controllers, etc
> +	 */

I don't believe that this actually turns out to be true (and yes I
know it is how I originally described it).  :-)  When the
interrupt-parent property is at the root of the tree, then the root
interrupt controller may very well inherit itself as it's interrupt
parent, and of_irq_find_parent() will still return a value.  This
should probably be considered a bug in of_irq_find_parent(), and it
should return NULL if the parent is itself.

of_irq_find_parent should probably be implemented thusly (completely
untested); although the only functional change is the line:
	return (p == child) ? NULL : p;

/**
 * of_irq_find_parent - Given a device node, find its interrupt parent node
 * @child: pointer to device node
 *
 * Returns a pointer to the interrupt parent node, or NULL if the
 * interrupt parent could not be determined.
 */
struct device_node *of_irq_find_parent(struct device_node *child)
{
	struct device_node *p, *c = child;
	const __be32 *parp;

	if (!of_node_get(c))
		return NULL;

	do {
		p = of_parse_phandle(c, "interrupt-parent", 0);

		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
		    of_find_property(c, "interrupt-parent", NULL))
			p = of_node_get(of_irq_dflt_pic);

		if (!p)
			p = of_get_parent(c);

		of_node_put(c);
		c = p;
	} while (p && !of_find_property(p, "#interrupt-cells", NULL));

	return (p == child) ? NULL : p;
}


> +	list_sort(NULL, &intc_desc_list, irq_cmp_intc_desc);
> +
> +	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> +		match = of_match_node(matches, desc->dev);
> +		if (match && match->data) {
> +			irq_init_cb_t irq_init_cb = match->data;
> +			pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> +				 match->compatible, desc->dev, desc->parent);
> +			irq_init_cb(desc->dev, desc->parent);
> +		}
> +		list_del(&desc->list);
> +		kfree(desc);
> +	}
> +	return;
> +
> +err:
> +	list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> +		list_del(&desc->list);
> +		kfree(desc);
> +	}
> +}

Overall, I'm pretty happy with how this is looking.  Great job!

g.

> diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
> index cd2e61c..032d76c 100644
> --- a/include/linux/of_irq.h
> +++ b/include/linux/of_irq.h
> @@ -73,6 +73,7 @@ extern int of_irq_to_resource_table(struct device_node *dev,
>  		struct resource *res, int nr_irqs);
>  extern struct device_node *of_irq_find_parent(struct device_node *child);
>  
> +extern void of_irq_init(const struct of_device_id *matches);
>  
>  #endif /* CONFIG_OF_IRQ */
>  #endif /* CONFIG_OF */
> -- 
> 1.7.5.4
> 

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Wed, Sep 14, 2011 at 01:51:42PM -0500, Rob Herring wrote:
> On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> > Hi Rob,
> > 
> > On 14/09/11 18:57, Rob Herring wrote:
> >> Marc,
> >>
> >> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
> >>> On 14/09/11 17:31, Rob Herring wrote:
> >>>> From: Rob Herring <rob.herring@calxeda.com>
> >>>>
> >>>> This adds gic initialization using device tree data. The initialization
> >>>> functions are intended to be called by a generic OF interrupt
> >>>> controller parsing function once the right pieces are in place.
> >>>>
> >>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>>> mask the PPI is assigned to.
> >>>>
> >>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>>>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> >>>> new file mode 100644
> >>>> index 0000000..6c513de
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> >>>> @@ -0,0 +1,53 @@
> >>>> +* ARM Generic Interrupt Controller
> >>>> +
> >>>> +ARM SMP cores are often associated with a GIC, providing per processor
> >>>> +interrupts (PPI), shared processor interrupts (SPI) and software
> >>>> +generated interrupts (SGI).
> >>>> +
> >>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> >>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
> >>>> +have PPIs or SGIs.
> >>>> +
> >>>> +Main node required properties:
> >>>> +
> >>>> +- compatible : should be one of:
> >>>> +	"arm,cortex-a9-gic"
> >>>> +	"arm,arm11mp-gic"
> >>>> +- interrupt-controller : Identifies the node as an interrupt controller
> >>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
> >>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> >>>> +
> >>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> >>>> +  for PPIs.
> >>>> +
> >>>> +  The 2nd cell is the level-sense information, encoded as follows:
> >>>> +                    1 = low-to-high edge triggered
> >>>> +                    2 = high-to-low edge triggered
> >>>> +                    4 = active high level-sensitive
> >>>> +                    8 = active low level-sensitive
> >>>> +
> >>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> >>>> +
> >>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> >>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> >>>> +  be 0 for PPIs.
> >>>      ^^^^^^^^^^^^^
> >>>
> >>> Typo here ? The way I understand it, it should read "For PPIs, this
> >>> value shall be the mask of the possible CPU numbers for the interrupt
> >>> source" (or something to similar effect...).
> >>>
> >>
> >> Cut and paste error. This sentence goes in the previous paragraph. What
> >> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
> >> edge/level on PPIs (that is always true, right?). I probably should also
> >> add 0 in the list of values.
> > 
> > Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> > this is defined by the hardware and cannot be configured. But it may be
> > interesting to have the DT to reflect the way the hardware is actually
> > configured (on the Cortex-A9, some PPIs are configured active-low, and
> > others are rising-edge).
> 
> So we should allow specifying what it is as the OS may need to know that.

If it is a difference between level & edge, then the OS absolutely
needs to know about it.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Wed, Sep 14, 2011 at 01:51:42PM -0500, Rob Herring wrote:
> On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> > Hi Rob,
> > 
> > On 14/09/11 18:57, Rob Herring wrote:
> >> Marc,
> >>
> >> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
> >>> On 14/09/11 17:31, Rob Herring wrote:
> >>>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> >>>>
> >>>> This adds gic initialization using device tree data. The initialization
> >>>> functions are intended to be called by a generic OF interrupt
> >>>> controller parsing function once the right pieces are in place.
> >>>>
> >>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>>> mask the PPI is assigned to.
> >>>>
> >>>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>>>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> >>>> new file mode 100644
> >>>> index 0000000..6c513de
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> >>>> @@ -0,0 +1,53 @@
> >>>> +* ARM Generic Interrupt Controller
> >>>> +
> >>>> +ARM SMP cores are often associated with a GIC, providing per processor
> >>>> +interrupts (PPI), shared processor interrupts (SPI) and software
> >>>> +generated interrupts (SGI).
> >>>> +
> >>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> >>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
> >>>> +have PPIs or SGIs.
> >>>> +
> >>>> +Main node required properties:
> >>>> +
> >>>> +- compatible : should be one of:
> >>>> +	"arm,cortex-a9-gic"
> >>>> +	"arm,arm11mp-gic"
> >>>> +- interrupt-controller : Identifies the node as an interrupt controller
> >>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
> >>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> >>>> +
> >>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> >>>> +  for PPIs.
> >>>> +
> >>>> +  The 2nd cell is the level-sense information, encoded as follows:
> >>>> +                    1 = low-to-high edge triggered
> >>>> +                    2 = high-to-low edge triggered
> >>>> +                    4 = active high level-sensitive
> >>>> +                    8 = active low level-sensitive
> >>>> +
> >>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> >>>> +
> >>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> >>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> >>>> +  be 0 for PPIs.
> >>>      ^^^^^^^^^^^^^
> >>>
> >>> Typo here ? The way I understand it, it should read "For PPIs, this
> >>> value shall be the mask of the possible CPU numbers for the interrupt
> >>> source" (or something to similar effect...).
> >>>
> >>
> >> Cut and paste error. This sentence goes in the previous paragraph. What
> >> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
> >> edge/level on PPIs (that is always true, right?). I probably should also
> >> add 0 in the list of values.
> > 
> > Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> > this is defined by the hardware and cannot be configured. But it may be
> > interesting to have the DT to reflect the way the hardware is actually
> > configured (on the Cortex-A9, some PPIs are configured active-low, and
> > others are rising-edge).
> 
> So we should allow specifying what it is as the OS may need to know that.

If it is a difference between level & edge, then the OS absolutely
needs to know about it.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Wed, Sep 14, 2011 at 01:51:42PM -0500, Rob Herring wrote:
> On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> > Hi Rob,
> > 
> > On 14/09/11 18:57, Rob Herring wrote:
> >> Marc,
> >>
> >> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
> >>> On 14/09/11 17:31, Rob Herring wrote:
> >>>> From: Rob Herring <rob.herring@calxeda.com>
> >>>>
> >>>> This adds gic initialization using device tree data. The initialization
> >>>> functions are intended to be called by a generic OF interrupt
> >>>> controller parsing function once the right pieces are in place.
> >>>>
> >>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>>> mask the PPI is assigned to.
> >>>>
> >>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>>>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>>>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>>>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>>>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> >>>> new file mode 100644
> >>>> index 0000000..6c513de
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> >>>> @@ -0,0 +1,53 @@
> >>>> +* ARM Generic Interrupt Controller
> >>>> +
> >>>> +ARM SMP cores are often associated with a GIC, providing per processor
> >>>> +interrupts (PPI), shared processor interrupts (SPI) and software
> >>>> +generated interrupts (SGI).
> >>>> +
> >>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> >>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
> >>>> +have PPIs or SGIs.
> >>>> +
> >>>> +Main node required properties:
> >>>> +
> >>>> +- compatible : should be one of:
> >>>> +	"arm,cortex-a9-gic"
> >>>> +	"arm,arm11mp-gic"
> >>>> +- interrupt-controller : Identifies the node as an interrupt controller
> >>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
> >>>> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> >>>> +
> >>>> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> >>>> +  for PPIs.
> >>>> +
> >>>> +  The 2nd cell is the level-sense information, encoded as follows:
> >>>> +                    1 = low-to-high edge triggered
> >>>> +                    2 = high-to-low edge triggered
> >>>> +                    4 = active high level-sensitive
> >>>> +                    8 = active low level-sensitive
> >>>> +
> >>>> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> >>>> +
> >>>> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> >>>> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> >>>> +  be 0 for PPIs.
> >>>      ^^^^^^^^^^^^^
> >>>
> >>> Typo here ? The way I understand it, it should read "For PPIs, this
> >>> value shall be the mask of the possible CPU numbers for the interrupt
> >>> source" (or something to similar effect...).
> >>>
> >>
> >> Cut and paste error. This sentence goes in the previous paragraph. What
> >> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
> >> edge/level on PPIs (that is always true, right?). I probably should also
> >> add 0 in the list of values.
> > 
> > Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> > this is defined by the hardware and cannot be configured. But it may be
> > interesting to have the DT to reflect the way the hardware is actually
> > configured (on the Cortex-A9, some PPIs are configured active-low, and
> > others are rising-edge).
> 
> So we should allow specifying what it is as the OS may need to know that.

If it is a difference between level & edge, then the OS absolutely
needs to know about it.

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Rob Herring]

Grant,

On 09/17/2011 06:53 PM, Grant Likely wrote:
> On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> of_irq_init will scan the devicetree for matching interrupt controller
>> nodes. Then it calls an initialization function for each found controller
>> in the proper order with parent nodes initialized before child nodes.
>>
>> Based on initial pseudo code from Grant Likely.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>  drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of_irq.h |    1 +
>>  2 files changed, 97 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
>> index 9f689f1..a0cd7e8 100644
>> --- a/drivers/of/irq.c
>> +++ b/drivers/of/irq.c
>> @@ -19,10 +19,13 @@
>>   */
>>  
>>  #include <linux/errno.h>
>> +#include <linux/list.h>
>> +#include <linux/list_sort.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/of_irq.h>
>>  #include <linux/string.h>
>> +#include <linux/slab.h>
>>  
>>  /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
>>  #ifndef NO_IRQ
>> @@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>>  
>>  	return i;
>>  }
>> +
>> +struct intc_desc {
>> +	struct list_head	list;
>> +	struct device_node	*dev;
>> +	struct device_node	*parent;
>> +};
>> +
>> +typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
>> +
>> +static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
>> +				    struct list_head *b)
>> +{
>> +	const struct intc_desc *da = list_entry(a, typeof(*da), list);
>> +	const struct intc_desc *db = list_entry(b, typeof(*db), list);
>> +
>> +	/* same parent, so order doesn't matter */
>> +	if (da->parent == db->parent)
>> +		return 0;
>> +
>> +	/* NULL parent comes first */
>> +	if (!da->parent && db->parent)
>> +		return -1;
>> +	if (!db->parent && da->parent)
>> +		return 1;
>> +
>> +	/* parent node must be before child node */
>> +	if (da->dev == db->parent)
>> +		return -1;
>> +	if (db->dev == da->parent)
>> +		return 1;
> 
> Does sort_list work for relationships 4 or more levels deep?  ie. if
> there was a relationship of A <- B <- C <- D, then B compared with D
> would return 0 from this function which could potentially result in an
> incorrectly ordered list.
> 

Doh! Um, 3 levels is enough for everyone!? ;)

> The other option for implementing this would be to take the probe
> deferral approach and not try to sort the list, but instead allow
> probe functions to fail & request retry if the parent hasn't yet been
> probed.  I haven't thought enough about it though to say which would
> be the best approach.
> 

Considering the list will typically be only a few entries, it is
probably not so important how efficiently we sort or walk the list.

The only way I see controller code knowing if it needs to defer init is
if of_irq_create_mapping fails. The core code could simply do this
itself. However, I would imagine sorting it would be faster than that path.

How about something like this (untested):

int find_order(struct intc_desc *node)
{
	struct intc_desc *d;

	list_for_each_entry(d, &intc_desc_list, list) {
		if (node->parent != d->dev)
			continue;

		if (d->order < 0)
			find_order(d);

		node->order = d->order + 1;
		break;
	}
}


Then rather than sorting, do this:


	list_for_each_entry(desc, &intc_desc_list, list)
		find_order(desc);

	for (order = 0; !list_empty(&intc_desc_list); order++) {
		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
			if (desc->order != order)
				continue;
			
			match = of_match_node(matches, desc->dev);
			if (match && match->data) {
				irq_init_cb_t irq_init_cb = match->data;
				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
					 match->compatible, desc->dev, desc->parent);
				irq_init_cb(desc->dev, desc->parent);
			}
			list_del(&desc->list);
			kfree(desc);
		}
	}


>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * of_irq_init - Scan the device tree for matching interrupt controllers and
>> + * call their initialization functions in order with parents first.
>> + * @matches: 0 terminated array of nodes to match and initialization function
>> + * to call on match
>> + */
>> +void __init of_irq_init(const struct of_device_id *matches)
>> +{
>> +	struct device_node *np;
>> +	const struct of_device_id *match;
>> +	struct intc_desc *desc;
>> +	struct intc_desc *temp_desc;
>> +	struct list_head intc_desc_list;
>> +
>> +	INIT_LIST_HEAD(&intc_desc_list);
>> +
>> +	for_each_matching_node(np, matches) {
>> +		if (!of_find_property(np, "interrupt-controller", NULL))
>> +			continue;
>> +		/* Here, we allocate and populate an intc_desc with the node
>> +		* pointer, interrupt-parent device_node etc. */
>> +		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
>> +		if (!desc) {
>> +			WARN_ON(1);
>> +			goto err;
>> +		}
>> +		desc->dev = np;
>> +		desc->parent = of_irq_find_parent(np);
>> +		list_add(&desc->list, &intc_desc_list);
>> +	}
>> +	if (list_empty(&intc_desc_list))
>> +		return;
>> +
>> +	/*
>> +	 * The root irq controller is the one without an interrupt-parent.
>> +	 * That one goes first, followed by the controllers that reference it,
>> +	 * followed by the ones that reference the 2nd level controllers, etc
>> +	 */
> 
> I don't believe that this actually turns out to be true (and yes I
> know it is how I originally described it).  :-)  When the
> interrupt-parent property is at the root of the tree, then the root
> interrupt controller may very well inherit itself as it's interrupt
> parent, and of_irq_find_parent() will still return a value.  This
> should probably be considered a bug in of_irq_find_parent(), and it
> should return NULL if the parent is itself.

I did hit this exact issue. There is an easy, but not obvious fix to the
device tree. Simply adding "interupt-parent;" to the root interrupt
controller node will do the trick and override the value in the tree root.

> 
> of_irq_find_parent should probably be implemented thusly (completely
> untested); although the only functional change is the line:
> 	return (p == child) ? NULL : p;
> 
> /**
>  * of_irq_find_parent - Given a device node, find its interrupt parent node
>  * @child: pointer to device node
>  *
>  * Returns a pointer to the interrupt parent node, or NULL if the
>  * interrupt parent could not be determined.
>  */
> struct device_node *of_irq_find_parent(struct device_node *child)
> {
> 	struct device_node *p, *c = child;
> 	const __be32 *parp;
> 
> 	if (!of_node_get(c))
> 		return NULL;
> 
> 	do {
> 		p = of_parse_phandle(c, "interrupt-parent", 0);
> 
> 		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
> 		    of_find_property(c, "interrupt-parent", NULL))
> 			p = of_node_get(of_irq_dflt_pic);
> 
> 		if (!p)
> 			p = of_get_parent(c);
> 
> 		of_node_put(c);
> 		c = p;
> 	} while (p && !of_find_property(p, "#interrupt-cells", NULL));
> 
> 	return (p == child) ? NULL : p;
> }
> 

This change should probably be implemented as well as this is likely a
common occurrence that will be stumbled over or existing device trees
won't have this. I'll test and add to the next series.

Rob

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Rob Herring]

Grant,

On 09/17/2011 06:53 PM, Grant Likely wrote:
> On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>
>> of_irq_init will scan the devicetree for matching interrupt controller
>> nodes. Then it calls an initialization function for each found controller
>> in the proper order with parent nodes initialized before child nodes.
>>
>> Based on initial pseudo code from Grant Likely.
>>
>> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>> ---
>>  drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of_irq.h |    1 +
>>  2 files changed, 97 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
>> index 9f689f1..a0cd7e8 100644
>> --- a/drivers/of/irq.c
>> +++ b/drivers/of/irq.c
>> @@ -19,10 +19,13 @@
>>   */
>>  
>>  #include <linux/errno.h>
>> +#include <linux/list.h>
>> +#include <linux/list_sort.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/of_irq.h>
>>  #include <linux/string.h>
>> +#include <linux/slab.h>
>>  
>>  /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
>>  #ifndef NO_IRQ
>> @@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>>  
>>  	return i;
>>  }
>> +
>> +struct intc_desc {
>> +	struct list_head	list;
>> +	struct device_node	*dev;
>> +	struct device_node	*parent;
>> +};
>> +
>> +typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
>> +
>> +static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
>> +				    struct list_head *b)
>> +{
>> +	const struct intc_desc *da = list_entry(a, typeof(*da), list);
>> +	const struct intc_desc *db = list_entry(b, typeof(*db), list);
>> +
>> +	/* same parent, so order doesn't matter */
>> +	if (da->parent == db->parent)
>> +		return 0;
>> +
>> +	/* NULL parent comes first */
>> +	if (!da->parent && db->parent)
>> +		return -1;
>> +	if (!db->parent && da->parent)
>> +		return 1;
>> +
>> +	/* parent node must be before child node */
>> +	if (da->dev == db->parent)
>> +		return -1;
>> +	if (db->dev == da->parent)
>> +		return 1;
> 
> Does sort_list work for relationships 4 or more levels deep?  ie. if
> there was a relationship of A <- B <- C <- D, then B compared with D
> would return 0 from this function which could potentially result in an
> incorrectly ordered list.
> 

Doh! Um, 3 levels is enough for everyone!? ;)

> The other option for implementing this would be to take the probe
> deferral approach and not try to sort the list, but instead allow
> probe functions to fail & request retry if the parent hasn't yet been
> probed.  I haven't thought enough about it though to say which would
> be the best approach.
> 

Considering the list will typically be only a few entries, it is
probably not so important how efficiently we sort or walk the list.

The only way I see controller code knowing if it needs to defer init is
if of_irq_create_mapping fails. The core code could simply do this
itself. However, I would imagine sorting it would be faster than that path.

How about something like this (untested):

int find_order(struct intc_desc *node)
{
	struct intc_desc *d;

	list_for_each_entry(d, &intc_desc_list, list) {
		if (node->parent != d->dev)
			continue;

		if (d->order < 0)
			find_order(d);

		node->order = d->order + 1;
		break;
	}
}


Then rather than sorting, do this:


	list_for_each_entry(desc, &intc_desc_list, list)
		find_order(desc);

	for (order = 0; !list_empty(&intc_desc_list); order++) {
		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
			if (desc->order != order)
				continue;
			
			match = of_match_node(matches, desc->dev);
			if (match && match->data) {
				irq_init_cb_t irq_init_cb = match->data;
				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
					 match->compatible, desc->dev, desc->parent);
				irq_init_cb(desc->dev, desc->parent);
			}
			list_del(&desc->list);
			kfree(desc);
		}
	}


>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * of_irq_init - Scan the device tree for matching interrupt controllers and
>> + * call their initialization functions in order with parents first.
>> + * @matches: 0 terminated array of nodes to match and initialization function
>> + * to call on match
>> + */
>> +void __init of_irq_init(const struct of_device_id *matches)
>> +{
>> +	struct device_node *np;
>> +	const struct of_device_id *match;
>> +	struct intc_desc *desc;
>> +	struct intc_desc *temp_desc;
>> +	struct list_head intc_desc_list;
>> +
>> +	INIT_LIST_HEAD(&intc_desc_list);
>> +
>> +	for_each_matching_node(np, matches) {
>> +		if (!of_find_property(np, "interrupt-controller", NULL))
>> +			continue;
>> +		/* Here, we allocate and populate an intc_desc with the node
>> +		* pointer, interrupt-parent device_node etc. */
>> +		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
>> +		if (!desc) {
>> +			WARN_ON(1);
>> +			goto err;
>> +		}
>> +		desc->dev = np;
>> +		desc->parent = of_irq_find_parent(np);
>> +		list_add(&desc->list, &intc_desc_list);
>> +	}
>> +	if (list_empty(&intc_desc_list))
>> +		return;
>> +
>> +	/*
>> +	 * The root irq controller is the one without an interrupt-parent.
>> +	 * That one goes first, followed by the controllers that reference it,
>> +	 * followed by the ones that reference the 2nd level controllers, etc
>> +	 */
> 
> I don't believe that this actually turns out to be true (and yes I
> know it is how I originally described it).  :-)  When the
> interrupt-parent property is at the root of the tree, then the root
> interrupt controller may very well inherit itself as it's interrupt
> parent, and of_irq_find_parent() will still return a value.  This
> should probably be considered a bug in of_irq_find_parent(), and it
> should return NULL if the parent is itself.

I did hit this exact issue. There is an easy, but not obvious fix to the
device tree. Simply adding "interupt-parent;" to the root interrupt
controller node will do the trick and override the value in the tree root.

> 
> of_irq_find_parent should probably be implemented thusly (completely
> untested); although the only functional change is the line:
> 	return (p == child) ? NULL : p;
> 
> /**
>  * of_irq_find_parent - Given a device node, find its interrupt parent node
>  * @child: pointer to device node
>  *
>  * Returns a pointer to the interrupt parent node, or NULL if the
>  * interrupt parent could not be determined.
>  */
> struct device_node *of_irq_find_parent(struct device_node *child)
> {
> 	struct device_node *p, *c = child;
> 	const __be32 *parp;
> 
> 	if (!of_node_get(c))
> 		return NULL;
> 
> 	do {
> 		p = of_parse_phandle(c, "interrupt-parent", 0);
> 
> 		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
> 		    of_find_property(c, "interrupt-parent", NULL))
> 			p = of_node_get(of_irq_dflt_pic);
> 
> 		if (!p)
> 			p = of_get_parent(c);
> 
> 		of_node_put(c);
> 		c = p;
> 	} while (p && !of_find_property(p, "#interrupt-cells", NULL));
> 
> 	return (p == child) ? NULL : p;
> }
> 

This change should probably be implemented as well as this is likely a
common occurrence that will be stumbled over or existing device trees
won't have this. I'll test and add to the next series.

Rob

[PATCH 3/5] of/irq: introduce of_irq_init

[Rob Herring]

Grant,

On 09/17/2011 06:53 PM, Grant Likely wrote:
> On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> of_irq_init will scan the devicetree for matching interrupt controller
>> nodes. Then it calls an initialization function for each found controller
>> in the proper order with parent nodes initialized before child nodes.
>>
>> Based on initial pseudo code from Grant Likely.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>  drivers/of/irq.c       |   96 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/of_irq.h |    1 +
>>  2 files changed, 97 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
>> index 9f689f1..a0cd7e8 100644
>> --- a/drivers/of/irq.c
>> +++ b/drivers/of/irq.c
>> @@ -19,10 +19,13 @@
>>   */
>>  
>>  #include <linux/errno.h>
>> +#include <linux/list.h>
>> +#include <linux/list_sort.h>
>>  #include <linux/module.h>
>>  #include <linux/of.h>
>>  #include <linux/of_irq.h>
>>  #include <linux/string.h>
>> +#include <linux/slab.h>
>>  
>>  /* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
>>  #ifndef NO_IRQ
>> @@ -386,3 +389,96 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
>>  
>>  	return i;
>>  }
>> +
>> +struct intc_desc {
>> +	struct list_head	list;
>> +	struct device_node	*dev;
>> +	struct device_node	*parent;
>> +};
>> +
>> +typedef void (*irq_init_cb_t)(struct device_node *, struct device_node *);
>> +
>> +static int __init irq_cmp_intc_desc(void *unused, struct list_head *a,
>> +				    struct list_head *b)
>> +{
>> +	const struct intc_desc *da = list_entry(a, typeof(*da), list);
>> +	const struct intc_desc *db = list_entry(b, typeof(*db), list);
>> +
>> +	/* same parent, so order doesn't matter */
>> +	if (da->parent == db->parent)
>> +		return 0;
>> +
>> +	/* NULL parent comes first */
>> +	if (!da->parent && db->parent)
>> +		return -1;
>> +	if (!db->parent && da->parent)
>> +		return 1;
>> +
>> +	/* parent node must be before child node */
>> +	if (da->dev == db->parent)
>> +		return -1;
>> +	if (db->dev == da->parent)
>> +		return 1;
> 
> Does sort_list work for relationships 4 or more levels deep?  ie. if
> there was a relationship of A <- B <- C <- D, then B compared with D
> would return 0 from this function which could potentially result in an
> incorrectly ordered list.
> 

Doh! Um, 3 levels is enough for everyone!? ;)

> The other option for implementing this would be to take the probe
> deferral approach and not try to sort the list, but instead allow
> probe functions to fail & request retry if the parent hasn't yet been
> probed.  I haven't thought enough about it though to say which would
> be the best approach.
> 

Considering the list will typically be only a few entries, it is
probably not so important how efficiently we sort or walk the list.

The only way I see controller code knowing if it needs to defer init is
if of_irq_create_mapping fails. The core code could simply do this
itself. However, I would imagine sorting it would be faster than that path.

How about something like this (untested):

int find_order(struct intc_desc *node)
{
	struct intc_desc *d;

	list_for_each_entry(d, &intc_desc_list, list) {
		if (node->parent != d->dev)
			continue;

		if (d->order < 0)
			find_order(d);

		node->order = d->order + 1;
		break;
	}
}


Then rather than sorting, do this:


	list_for_each_entry(desc, &intc_desc_list, list)
		find_order(desc);

	for (order = 0; !list_empty(&intc_desc_list); order++) {
		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
			if (desc->order != order)
				continue;
			
			match = of_match_node(matches, desc->dev);
			if (match && match->data) {
				irq_init_cb_t irq_init_cb = match->data;
				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
					 match->compatible, desc->dev, desc->parent);
				irq_init_cb(desc->dev, desc->parent);
			}
			list_del(&desc->list);
			kfree(desc);
		}
	}


>> +
>> +	return 0;
>> +}
>> +
>> +/**
>> + * of_irq_init - Scan the device tree for matching interrupt controllers and
>> + * call their initialization functions in order with parents first.
>> + * @matches: 0 terminated array of nodes to match and initialization function
>> + * to call on match
>> + */
>> +void __init of_irq_init(const struct of_device_id *matches)
>> +{
>> +	struct device_node *np;
>> +	const struct of_device_id *match;
>> +	struct intc_desc *desc;
>> +	struct intc_desc *temp_desc;
>> +	struct list_head intc_desc_list;
>> +
>> +	INIT_LIST_HEAD(&intc_desc_list);
>> +
>> +	for_each_matching_node(np, matches) {
>> +		if (!of_find_property(np, "interrupt-controller", NULL))
>> +			continue;
>> +		/* Here, we allocate and populate an intc_desc with the node
>> +		* pointer, interrupt-parent device_node etc. */
>> +		desc = kzalloc(sizeof(*desc), GFP_KERNEL);
>> +		if (!desc) {
>> +			WARN_ON(1);
>> +			goto err;
>> +		}
>> +		desc->dev = np;
>> +		desc->parent = of_irq_find_parent(np);
>> +		list_add(&desc->list, &intc_desc_list);
>> +	}
>> +	if (list_empty(&intc_desc_list))
>> +		return;
>> +
>> +	/*
>> +	 * The root irq controller is the one without an interrupt-parent.
>> +	 * That one goes first, followed by the controllers that reference it,
>> +	 * followed by the ones that reference the 2nd level controllers, etc
>> +	 */
> 
> I don't believe that this actually turns out to be true (and yes I
> know it is how I originally described it).  :-)  When the
> interrupt-parent property is at the root of the tree, then the root
> interrupt controller may very well inherit itself as it's interrupt
> parent, and of_irq_find_parent() will still return a value.  This
> should probably be considered a bug in of_irq_find_parent(), and it
> should return NULL if the parent is itself.

I did hit this exact issue. There is an easy, but not obvious fix to the
device tree. Simply adding "interupt-parent;" to the root interrupt
controller node will do the trick and override the value in the tree root.

> 
> of_irq_find_parent should probably be implemented thusly (completely
> untested); although the only functional change is the line:
> 	return (p == child) ? NULL : p;
> 
> /**
>  * of_irq_find_parent - Given a device node, find its interrupt parent node
>  * @child: pointer to device node
>  *
>  * Returns a pointer to the interrupt parent node, or NULL if the
>  * interrupt parent could not be determined.
>  */
> struct device_node *of_irq_find_parent(struct device_node *child)
> {
> 	struct device_node *p, *c = child;
> 	const __be32 *parp;
> 
> 	if (!of_node_get(c))
> 		return NULL;
> 
> 	do {
> 		p = of_parse_phandle(c, "interrupt-parent", 0);
> 
> 		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
> 		    of_find_property(c, "interrupt-parent", NULL))
> 			p = of_node_get(of_irq_dflt_pic);
> 
> 		if (!p)
> 			p = of_get_parent(c);
> 
> 		of_node_put(c);
> 		c = p;
> 	} while (p && !of_find_property(p, "#interrupt-cells", NULL));
> 
> 	return (p == child) ? NULL : p;
> }
> 

This change should probably be implemented as well as this is likely a
common occurrence that will be stumbled over or existing device trees
won't have this. I'll test and add to the next series.

Rob

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Grant Likely]

On Sat, Sep 17, 2011 at 08:37:26PM -0500, Rob Herring wrote:
> Grant,
> 
> On 09/17/2011 06:53 PM, Grant Likely wrote:
> > On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
> > The other option for implementing this would be to take the probe
> > deferral approach and not try to sort the list, but instead allow
> > probe functions to fail & request retry if the parent hasn't yet been
> > probed.  I haven't thought enough about it though to say which would
> > be the best approach.
> > 
> 
> Considering the list will typically be only a few entries, it is
> probably not so important how efficiently we sort or walk the list.
> 
> The only way I see controller code knowing if it needs to defer init is
> if of_irq_create_mapping fails. The core code could simply do this
> itself. However, I would imagine sorting it would be faster than that path.
> 
> How about something like this (untested):
> 
> int find_order(struct intc_desc *node)
> {
> 	struct intc_desc *d;
> 
> 	list_for_each_entry(d, &intc_desc_list, list) {
> 		if (node->parent != d->dev)
> 			continue;
> 
> 		if (d->order < 0)
> 			find_order(d);
> 
> 		node->order = d->order + 1;
> 		break;
> 	}
> }
> 
> 
> Then rather than sorting, do this:
> 
> 
> 	list_for_each_entry(desc, &intc_desc_list, list)
> 		find_order(desc);
> 
> 	for (order = 0; !list_empty(&intc_desc_list); order++) {
> 		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> 			if (desc->order != order)
> 				continue;
> 			
> 			match = of_match_node(matches, desc->dev);
> 			if (match && match->data) {
> 				irq_init_cb_t irq_init_cb = match->data;
> 				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> 					 match->compatible, desc->dev, desc->parent);
> 				irq_init_cb(desc->dev, desc->parent);
> 			}
> 			list_del(&desc->list);
> 			kfree(desc);
> 		}
> 	}

I don't think there needs to be a separate pass for calculating order.
What about a breadth-first search with a secondary list for pending
parents?  Something like:


	struct list_head intc_desc_list;
	struct list_head intc_parent_list;
	struct device_node *parent = NULL;

	while (!list_empty(&intc_desc_list)) {
		/*
		 * Process all controllers with the current 'parent'.
		 * First pass will be looking for NULL as the parent.
		 * The assumption is that NULL parent means a root
		 * controller
		 */
		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
			if (desc->parent == parent) {
				list_del(&desc->list);
				irq_init_cb_t irq_init_cb = match->data;
				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
					 match->compatible, desc->dev, desc->parent);
				irq_init_cb(desc->dev, desc->parent);

				/*
				 * This one is now set up; add it to
				 * the parent list so its children
				 * can get processed in a subsequent
				 * pass.
				 */
				list_add_tail(&desc->list, &intc_parent_list);
			}
		}

		/* Get the next pending parent that might have children */
		desc = list_first_entry(&intc_parent_list, typeof(*desc), list);
		if (!desc) {
			pr_error("Danger Will Robinson!");
			break;
		}
		list_del(&desc->list);
		parent = desc->list
		kfree(desc);
	}

> >> +	/*
> >> +	 * The root irq controller is the one without an interrupt-parent.
> >> +	 * That one goes first, followed by the controllers that reference it,
> >> +	 * followed by the ones that reference the 2nd level controllers, etc
> >> +	 */
> > 
> > I don't believe that this actually turns out to be true (and yes I
> > know it is how I originally described it).  :-)  When the
> > interrupt-parent property is at the root of the tree, then the root
> > interrupt controller may very well inherit itself as it's interrupt
> > parent, and of_irq_find_parent() will still return a value.  This
> > should probably be considered a bug in of_irq_find_parent(), and it
> > should return NULL if the parent is itself.
> 
> I did hit this exact issue. There is an easy, but not obvious fix to the
> device tree. Simply adding "interupt-parent;" to the root interrupt
> controller node will do the trick and override the value in the tree root.

Hahaha.  Definitely a bug then.

> > of_irq_find_parent should probably be implemented thusly (completely
> > untested); although the only functional change is the line:
> > 	return (p == child) ? NULL : p;
> > 
> > /**
> >  * of_irq_find_parent - Given a device node, find its interrupt parent node
> >  * @child: pointer to device node
> >  *
> >  * Returns a pointer to the interrupt parent node, or NULL if the
> >  * interrupt parent could not be determined.
> >  */
> > struct device_node *of_irq_find_parent(struct device_node *child)
> > {
> > 	struct device_node *p, *c = child;
> > 	const __be32 *parp;
> > 
> > 	if (!of_node_get(c))
> > 		return NULL;
> > 
> > 	do {
> > 		p = of_parse_phandle(c, "interrupt-parent", 0);
> > 
> > 		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
> > 		    of_find_property(c, "interrupt-parent", NULL))
> > 			p = of_node_get(of_irq_dflt_pic);
> > 
> > 		if (!p)
> > 			p = of_get_parent(c);
> > 
> > 		of_node_put(c);
> > 		c = p;
> > 	} while (p && !of_find_property(p, "#interrupt-cells", NULL));
> > 
> > 	return (p == child) ? NULL : p;
> > }
> > 
> 
> This change should probably be implemented as well as this is likely a
> common occurrence that will be stumbled over or existing device trees
> won't have this.

Existing device trees probably do have this, but all the powerpc board
support currently hard codes the interrupt controller setup.  They
will hit the same issue if converted to use this approach.

> I'll test and add to the next series.

Awesome, thanks!

g.

Re: [PATCH 3/5] of/irq: introduce of_irq_init

[Grant Likely]

On Sat, Sep 17, 2011 at 08:37:26PM -0500, Rob Herring wrote:
> Grant,
> 
> On 09/17/2011 06:53 PM, Grant Likely wrote:
> > On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
> > The other option for implementing this would be to take the probe
> > deferral approach and not try to sort the list, but instead allow
> > probe functions to fail & request retry if the parent hasn't yet been
> > probed.  I haven't thought enough about it though to say which would
> > be the best approach.
> > 
> 
> Considering the list will typically be only a few entries, it is
> probably not so important how efficiently we sort or walk the list.
> 
> The only way I see controller code knowing if it needs to defer init is
> if of_irq_create_mapping fails. The core code could simply do this
> itself. However, I would imagine sorting it would be faster than that path.
> 
> How about something like this (untested):
> 
> int find_order(struct intc_desc *node)
> {
> 	struct intc_desc *d;
> 
> 	list_for_each_entry(d, &intc_desc_list, list) {
> 		if (node->parent != d->dev)
> 			continue;
> 
> 		if (d->order < 0)
> 			find_order(d);
> 
> 		node->order = d->order + 1;
> 		break;
> 	}
> }
> 
> 
> Then rather than sorting, do this:
> 
> 
> 	list_for_each_entry(desc, &intc_desc_list, list)
> 		find_order(desc);
> 
> 	for (order = 0; !list_empty(&intc_desc_list); order++) {
> 		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> 			if (desc->order != order)
> 				continue;
> 			
> 			match = of_match_node(matches, desc->dev);
> 			if (match && match->data) {
> 				irq_init_cb_t irq_init_cb = match->data;
> 				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> 					 match->compatible, desc->dev, desc->parent);
> 				irq_init_cb(desc->dev, desc->parent);
> 			}
> 			list_del(&desc->list);
> 			kfree(desc);
> 		}
> 	}

I don't think there needs to be a separate pass for calculating order.
What about a breadth-first search with a secondary list for pending
parents?  Something like:


	struct list_head intc_desc_list;
	struct list_head intc_parent_list;
	struct device_node *parent = NULL;

	while (!list_empty(&intc_desc_list)) {
		/*
		 * Process all controllers with the current 'parent'.
		 * First pass will be looking for NULL as the parent.
		 * The assumption is that NULL parent means a root
		 * controller
		 */
		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
			if (desc->parent == parent) {
				list_del(&desc->list);
				irq_init_cb_t irq_init_cb = match->data;
				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
					 match->compatible, desc->dev, desc->parent);
				irq_init_cb(desc->dev, desc->parent);

				/*
				 * This one is now set up; add it to
				 * the parent list so its children
				 * can get processed in a subsequent
				 * pass.
				 */
				list_add_tail(&desc->list, &intc_parent_list);
			}
		}

		/* Get the next pending parent that might have children */
		desc = list_first_entry(&intc_parent_list, typeof(*desc), list);
		if (!desc) {
			pr_error("Danger Will Robinson!");
			break;
		}
		list_del(&desc->list);
		parent = desc->list
		kfree(desc);
	}

> >> +	/*
> >> +	 * The root irq controller is the one without an interrupt-parent.
> >> +	 * That one goes first, followed by the controllers that reference it,
> >> +	 * followed by the ones that reference the 2nd level controllers, etc
> >> +	 */
> > 
> > I don't believe that this actually turns out to be true (and yes I
> > know it is how I originally described it).  :-)  When the
> > interrupt-parent property is at the root of the tree, then the root
> > interrupt controller may very well inherit itself as it's interrupt
> > parent, and of_irq_find_parent() will still return a value.  This
> > should probably be considered a bug in of_irq_find_parent(), and it
> > should return NULL if the parent is itself.
> 
> I did hit this exact issue. There is an easy, but not obvious fix to the
> device tree. Simply adding "interupt-parent;" to the root interrupt
> controller node will do the trick and override the value in the tree root.

Hahaha.  Definitely a bug then.

> > of_irq_find_parent should probably be implemented thusly (completely
> > untested); although the only functional change is the line:
> > 	return (p == child) ? NULL : p;
> > 
> > /**
> >  * of_irq_find_parent - Given a device node, find its interrupt parent node
> >  * @child: pointer to device node
> >  *
> >  * Returns a pointer to the interrupt parent node, or NULL if the
> >  * interrupt parent could not be determined.
> >  */
> > struct device_node *of_irq_find_parent(struct device_node *child)
> > {
> > 	struct device_node *p, *c = child;
> > 	const __be32 *parp;
> > 
> > 	if (!of_node_get(c))
> > 		return NULL;
> > 
> > 	do {
> > 		p = of_parse_phandle(c, "interrupt-parent", 0);
> > 
> > 		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
> > 		    of_find_property(c, "interrupt-parent", NULL))
> > 			p = of_node_get(of_irq_dflt_pic);
> > 
> > 		if (!p)
> > 			p = of_get_parent(c);
> > 
> > 		of_node_put(c);
> > 		c = p;
> > 	} while (p && !of_find_property(p, "#interrupt-cells", NULL));
> > 
> > 	return (p == child) ? NULL : p;
> > }
> > 
> 
> This change should probably be implemented as well as this is likely a
> common occurrence that will be stumbled over or existing device trees
> won't have this.

Existing device trees probably do have this, but all the powerpc board
support currently hard codes the interrupt controller setup.  They
will hit the same issue if converted to use this approach.

> I'll test and add to the next series.

Awesome, thanks!

g.

[PATCH 3/5] of/irq: introduce of_irq_init

[Grant Likely]

On Sat, Sep 17, 2011 at 08:37:26PM -0500, Rob Herring wrote:
> Grant,
> 
> On 09/17/2011 06:53 PM, Grant Likely wrote:
> > On Wed, Sep 14, 2011 at 11:31:38AM -0500, Rob Herring wrote:
> > The other option for implementing this would be to take the probe
> > deferral approach and not try to sort the list, but instead allow
> > probe functions to fail & request retry if the parent hasn't yet been
> > probed.  I haven't thought enough about it though to say which would
> > be the best approach.
> > 
> 
> Considering the list will typically be only a few entries, it is
> probably not so important how efficiently we sort or walk the list.
> 
> The only way I see controller code knowing if it needs to defer init is
> if of_irq_create_mapping fails. The core code could simply do this
> itself. However, I would imagine sorting it would be faster than that path.
> 
> How about something like this (untested):
> 
> int find_order(struct intc_desc *node)
> {
> 	struct intc_desc *d;
> 
> 	list_for_each_entry(d, &intc_desc_list, list) {
> 		if (node->parent != d->dev)
> 			continue;
> 
> 		if (d->order < 0)
> 			find_order(d);
> 
> 		node->order = d->order + 1;
> 		break;
> 	}
> }
> 
> 
> Then rather than sorting, do this:
> 
> 
> 	list_for_each_entry(desc, &intc_desc_list, list)
> 		find_order(desc);
> 
> 	for (order = 0; !list_empty(&intc_desc_list); order++) {
> 		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
> 			if (desc->order != order)
> 				continue;
> 			
> 			match = of_match_node(matches, desc->dev);
> 			if (match && match->data) {
> 				irq_init_cb_t irq_init_cb = match->data;
> 				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
> 					 match->compatible, desc->dev, desc->parent);
> 				irq_init_cb(desc->dev, desc->parent);
> 			}
> 			list_del(&desc->list);
> 			kfree(desc);
> 		}
> 	}

I don't think there needs to be a separate pass for calculating order.
What about a breadth-first search with a secondary list for pending
parents?  Something like:


	struct list_head intc_desc_list;
	struct list_head intc_parent_list;
	struct device_node *parent = NULL;

	while (!list_empty(&intc_desc_list)) {
		/*
		 * Process all controllers with the current 'parent'.
		 * First pass will be looking for NULL as the parent.
		 * The assumption is that NULL parent means a root
		 * controller
		 */
		list_for_each_entry_safe(desc, temp_desc, &intc_desc_list, list) {
			if (desc->parent == parent) {
				list_del(&desc->list);
				irq_init_cb_t irq_init_cb = match->data;
				pr_debug("of_irq_init: init %s @ %p, parent %p\n",
					 match->compatible, desc->dev, desc->parent);
				irq_init_cb(desc->dev, desc->parent);

				/*
				 * This one is now set up; add it to
				 * the parent list so its children
				 * can get processed in a subsequent
				 * pass.
				 */
				list_add_tail(&desc->list, &intc_parent_list);
			}
		}

		/* Get the next pending parent that might have children */
		desc = list_first_entry(&intc_parent_list, typeof(*desc), list);
		if (!desc) {
			pr_error("Danger Will Robinson!");
			break;
		}
		list_del(&desc->list);
		parent = desc->list
		kfree(desc);
	}

> >> +	/*
> >> +	 * The root irq controller is the one without an interrupt-parent.
> >> +	 * That one goes first, followed by the controllers that reference it,
> >> +	 * followed by the ones that reference the 2nd level controllers, etc
> >> +	 */
> > 
> > I don't believe that this actually turns out to be true (and yes I
> > know it is how I originally described it).  :-)  When the
> > interrupt-parent property is at the root of the tree, then the root
> > interrupt controller may very well inherit itself as it's interrupt
> > parent, and of_irq_find_parent() will still return a value.  This
> > should probably be considered a bug in of_irq_find_parent(), and it
> > should return NULL if the parent is itself.
> 
> I did hit this exact issue. There is an easy, but not obvious fix to the
> device tree. Simply adding "interupt-parent;" to the root interrupt
> controller node will do the trick and override the value in the tree root.

Hahaha.  Definitely a bug then.

> > of_irq_find_parent should probably be implemented thusly (completely
> > untested); although the only functional change is the line:
> > 	return (p == child) ? NULL : p;
> > 
> > /**
> >  * of_irq_find_parent - Given a device node, find its interrupt parent node
> >  * @child: pointer to device node
> >  *
> >  * Returns a pointer to the interrupt parent node, or NULL if the
> >  * interrupt parent could not be determined.
> >  */
> > struct device_node *of_irq_find_parent(struct device_node *child)
> > {
> > 	struct device_node *p, *c = child;
> > 	const __be32 *parp;
> > 
> > 	if (!of_node_get(c))
> > 		return NULL;
> > 
> > 	do {
> > 		p = of_parse_phandle(c, "interrupt-parent", 0);
> > 
> > 		if (!p && (of_irq_workarounds & OF_IMAP_NO_PHANDLE) &&
> > 		    of_find_property(c, "interrupt-parent", NULL))
> > 			p = of_node_get(of_irq_dflt_pic);
> > 
> > 		if (!p)
> > 			p = of_get_parent(c);
> > 
> > 		of_node_put(c);
> > 		c = p;
> > 	} while (p && !of_find_property(p, "#interrupt-cells", NULL));
> > 
> > 	return (p == child) ? NULL : p;
> > }
> > 
> 
> This change should probably be implemented as well as this is likely a
> common occurrence that will be stumbled over or existing device trees
> won't have this.

Existing device trees probably do have this, but all the powerpc board
support currently hard codes the interrupt controller setup.  They
will hit the same issue if converted to use this approach.

> I'll test and add to the next series.

Awesome, thanks!

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
> Hi Rob,
> 
> On 15 September 2011 18:24, Rob Herring <robherring2@gmail.com> wrote:
> > On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> >>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>> +{
> >>> +       void __iomem *cpu_base;
> >>> +       void __iomem *dist_base;
> >>> +       int irq;
> >>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
> >>> +
> >>> +       if (WARN_ON(!node))
> >>> +               return;
> >>> +
> >>> +       dist_base = of_iomap(node, 0);
> >>> +       WARN(!dist_base, "unable to map gic dist registers\n");
> >>> +
> >>> +       cpu_base = of_iomap(node, 1);
> >>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>> +
> >>> +       domain->nr_irq = gic_irq_count(dist_base);
> >>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >>
> >> For exynos4, all the interrupts originating from GIC are statically
> >> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >> start from 64). In the above code, since irq_base would be 0 for
> >> exynos4, the interrupt mapping is not working correctly. In your
> >> previous version of the patch, you have given a option to the platform
> >> code to choose the offset. Could that option be added to this series
> >> also. Or a provision to use platform specific translate function
> >> instead of the irq_domain_simple translator.
> >>
> >
> > So I guess you have the A9 external nIRQ hooked up to another
> > controller? Why can't the 0-31 interrupts get mapped to after the gic
> > interrupts? Ultimately we want h/w irq numbers completely decoupled from
> > linux irq numbers. So you will want to put that controller in devicetree
> > and have an DT init function for it as well.
> 
> There are chained interrupt handlers mapped in between linux irq
> number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
> = 32). The interrupt chaining for the interrupts mapped between 0 to
> 31 seems unnecessary though. I will try removing them and check.

Please note; when using the DT, the linux virq number should be
dynamically assigned and therefore will not matter.  Historically
Exynos may have started from irq 32, but it doesn't really have any
relevance when all IRQ references are via DT irq specifiers.

Plus, for dynamically allocated irq_descs, I really want to make sure
that irq 0 never gets assigned.  We're not supposed to be using it,
and that becomes an easy rule to enforce when interrupt numbers are no
longer assigned with #defines.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
> Hi Rob,
> 
> On 15 September 2011 18:24, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> >>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>> +{
> >>> +       void __iomem *cpu_base;
> >>> +       void __iomem *dist_base;
> >>> +       int irq;
> >>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
> >>> +
> >>> +       if (WARN_ON(!node))
> >>> +               return;
> >>> +
> >>> +       dist_base = of_iomap(node, 0);
> >>> +       WARN(!dist_base, "unable to map gic dist registers\n");
> >>> +
> >>> +       cpu_base = of_iomap(node, 1);
> >>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>> +
> >>> +       domain->nr_irq = gic_irq_count(dist_base);
> >>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >>
> >> For exynos4, all the interrupts originating from GIC are statically
> >> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >> start from 64). In the above code, since irq_base would be 0 for
> >> exynos4, the interrupt mapping is not working correctly. In your
> >> previous version of the patch, you have given a option to the platform
> >> code to choose the offset. Could that option be added to this series
> >> also. Or a provision to use platform specific translate function
> >> instead of the irq_domain_simple translator.
> >>
> >
> > So I guess you have the A9 external nIRQ hooked up to another
> > controller? Why can't the 0-31 interrupts get mapped to after the gic
> > interrupts? Ultimately we want h/w irq numbers completely decoupled from
> > linux irq numbers. So you will want to put that controller in devicetree
> > and have an DT init function for it as well.
> 
> There are chained interrupt handlers mapped in between linux irq
> number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
> = 32). The interrupt chaining for the interrupts mapped between 0 to
> 31 seems unnecessary though. I will try removing them and check.

Please note; when using the DT, the linux virq number should be
dynamically assigned and therefore will not matter.  Historically
Exynos may have started from irq 32, but it doesn't really have any
relevance when all IRQ references are via DT irq specifiers.

Plus, for dynamically allocated irq_descs, I really want to make sure
that irq 0 never gets assigned.  We're not supposed to be using it,
and that becomes an easy rule to enforce when interrupt numbers are no
longer assigned with #defines.

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
> Hi Rob,
> 
> On 15 September 2011 18:24, Rob Herring <robherring2@gmail.com> wrote:
> > On 09/15/2011 02:55 AM, Thomas Abraham wrote:
> >>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>> +{
> >>> + ? ? ? void __iomem *cpu_base;
> >>> + ? ? ? void __iomem *dist_base;
> >>> + ? ? ? int irq;
> >>> + ? ? ? struct irq_domain *domain = &gic_data[gic_cnt].domain;
> >>> +
> >>> + ? ? ? if (WARN_ON(!node))
> >>> + ? ? ? ? ? ? ? return;
> >>> +
> >>> + ? ? ? dist_base = of_iomap(node, 0);
> >>> + ? ? ? WARN(!dist_base, "unable to map gic dist registers\n");
> >>> +
> >>> + ? ? ? cpu_base = of_iomap(node, 1);
> >>> + ? ? ? WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>> +
> >>> + ? ? ? domain->nr_irq = gic_irq_count(dist_base);
> >>> + ? ? ? domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >>
> >> For exynos4, all the interrupts originating from GIC are statically
> >> mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >> start from 64). In the above code, since irq_base would be 0 for
> >> exynos4, the interrupt mapping is not working correctly. In your
> >> previous version of the patch, you have given a option to the platform
> >> code to choose the offset. Could that option be added to this series
> >> also. Or a provision to use platform specific translate function
> >> instead of the irq_domain_simple translator.
> >>
> >
> > So I guess you have the A9 external nIRQ hooked up to another
> > controller? Why can't the 0-31 interrupts get mapped to after the gic
> > interrupts? Ultimately we want h/w irq numbers completely decoupled from
> > linux irq numbers. So you will want to put that controller in devicetree
> > and have an DT init function for it as well.
> 
> There are chained interrupt handlers mapped in between linux irq
> number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
> = 32). The interrupt chaining for the interrupts mapped between 0 to
> 31 seems unnecessary though. I will try removing them and check.

Please note; when using the DT, the linux virq number should be
dynamically assigned and therefore will not matter.  Historically
Exynos may have started from irq 32, but it doesn't really have any
relevance when all IRQ references are via DT irq specifiers.

Plus, for dynamically allocated irq_descs, I really want to make sure
that irq 0 never gets assigned.  We're not supposed to be using it,
and that becomes an easy rule to enforce when interrupt numbers are no
longer assigned with #defines.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> >Hi Rob,
> >
> >On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
> >>From: Rob Herring<rob.herring@calxeda.com>
> >>
> >>This adds gic initialization using device tree data. The initialization
> >>functions are intended to be called by a generic OF interrupt
> >>controller parsing function once the right pieces are in place.
> >>
> >>PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>mask the PPI is assigned to.
> >>
> >>Signed-off-by: Rob Herring<rob.herring@calxeda.com>
> >>---
> >>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >
> >[...]
> >
> >
> >>diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >>index d1ccc72..14de380 100644
> >>--- a/arch/arm/common/gic.c
> >>+++ b/arch/arm/common/gic.c
> >
> >[...]
> >
> >>+void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>+{
> >>+       void __iomem *cpu_base;
> >>+       void __iomem *dist_base;
> >>+       int irq;
> >>+       struct irq_domain *domain =&gic_data[gic_cnt].domain;
> >>+
> >>+       if (WARN_ON(!node))
> >>+               return;
> >>+
> >>+       dist_base = of_iomap(node, 0);
> >>+       WARN(!dist_base, "unable to map gic dist registers\n");
> >>+
> >>+       cpu_base = of_iomap(node, 1);
> >>+       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>+
> >>+       domain->nr_irq = gic_irq_count(dist_base);
> >>+       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >
> >For exynos4, all the interrupts originating from GIC are statically
> >mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >start from 64). In the above code, since irq_base would be 0 for
> >exynos4, the interrupt mapping is not working correctly. In your
> >previous version of the patch, you have given a option to the platform
> >code to choose the offset. Could that option be added to this series
> >also. Or a provision to use platform specific translate function
> >instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
> of 32. Only the internal PPI are between 0 and 31.
> 
> For the moment we add 32 to every SoC interrupts in the irq.h
> define, but I'm assuming that this offset calculation should be done
> thanks to a dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value
> that should be in the irq binding of the device.

Yes.

> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.

Part of the purpose behind irq_domains is to have a translator
callback that can take care of complex mappings, such as mapping each
of the GIC irq ranges onto the Linux irq space.  Plus, by being based
on the DT irq specifiers and dynamically assigning the linux numbers,
the actual mapping that the kernel chooses to use shouldn't actually
have any relevance.  So whether or not the driver uses an offset is 32
becomes an implementation detail.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> >Hi Rob,
> >
> >On 14 September 2011 22:01, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
> >>From: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> >>
> >>This adds gic initialization using device tree data. The initialization
> >>functions are intended to be called by a generic OF interrupt
> >>controller parsing function once the right pieces are in place.
> >>
> >>PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>mask the PPI is assigned to.
> >>
> >>Signed-off-by: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> >>---
> >>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >
> >[...]
> >
> >
> >>diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >>index d1ccc72..14de380 100644
> >>--- a/arch/arm/common/gic.c
> >>+++ b/arch/arm/common/gic.c
> >
> >[...]
> >
> >>+void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>+{
> >>+       void __iomem *cpu_base;
> >>+       void __iomem *dist_base;
> >>+       int irq;
> >>+       struct irq_domain *domain =&gic_data[gic_cnt].domain;
> >>+
> >>+       if (WARN_ON(!node))
> >>+               return;
> >>+
> >>+       dist_base = of_iomap(node, 0);
> >>+       WARN(!dist_base, "unable to map gic dist registers\n");
> >>+
> >>+       cpu_base = of_iomap(node, 1);
> >>+       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>+
> >>+       domain->nr_irq = gic_irq_count(dist_base);
> >>+       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >
> >For exynos4, all the interrupts originating from GIC are statically
> >mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >start from 64). In the above code, since irq_base would be 0 for
> >exynos4, the interrupt mapping is not working correctly. In your
> >previous version of the patch, you have given a option to the platform
> >code to choose the offset. Could that option be added to this series
> >also. Or a provision to use platform specific translate function
> >instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
> of 32. Only the internal PPI are between 0 and 31.
> 
> For the moment we add 32 to every SoC interrupts in the irq.h
> define, but I'm assuming that this offset calculation should be done
> thanks to a dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value
> that should be in the irq binding of the device.

Yes.

> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.

Part of the purpose behind irq_domains is to have a translator
callback that can take care of complex mappings, such as mapping each
of the GIC irq ranges onto the Linux irq space.  Plus, by being based
on the DT irq specifiers and dynamically assigning the linux numbers,
the actual mapping that the kernel chooses to use shouldn't actually
have any relevance.  So whether or not the driver uses an offset is 32
becomes an implementation detail.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
> Hi Rob,
> 
> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
> >Hi Rob,
> >
> >On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>  wrote:
> >>From: Rob Herring<rob.herring@calxeda.com>
> >>
> >>This adds gic initialization using device tree data. The initialization
> >>functions are intended to be called by a generic OF interrupt
> >>controller parsing function once the right pieces are in place.
> >>
> >>PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> >>mask the PPI is assigned to.
> >>
> >>Signed-off-by: Rob Herring<rob.herring@calxeda.com>
> >>---
> >>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
> >>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
> >>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
> >>  3 files changed, 114 insertions(+), 4 deletions(-)
> >>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> >
> >[...]
> >
> >
> >>diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> >>index d1ccc72..14de380 100644
> >>--- a/arch/arm/common/gic.c
> >>+++ b/arch/arm/common/gic.c
> >
> >[...]
> >
> >>+void __init gic_of_init(struct device_node *node, struct device_node *parent)
> >>+{
> >>+       void __iomem *cpu_base;
> >>+       void __iomem *dist_base;
> >>+       int irq;
> >>+       struct irq_domain *domain =&gic_data[gic_cnt].domain;
> >>+
> >>+       if (WARN_ON(!node))
> >>+               return;
> >>+
> >>+       dist_base = of_iomap(node, 0);
> >>+       WARN(!dist_base, "unable to map gic dist registers\n");
> >>+
> >>+       cpu_base = of_iomap(node, 1);
> >>+       WARN(!cpu_base, "unable to map gic cpu registers\n");
> >>+
> >>+       domain->nr_irq = gic_irq_count(dist_base);
> >>+       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
> >
> >For exynos4, all the interrupts originating from GIC are statically
> >mapped to start from 32 in the linux virq space (GIC SPI interrupts
> >start from 64). In the above code, since irq_base would be 0 for
> >exynos4, the interrupt mapping is not working correctly. In your
> >previous version of the patch, you have given a option to the platform
> >code to choose the offset. Could that option be added to this series
> >also. Or a provision to use platform specific translate function
> >instead of the irq_domain_simple translator.
> 
> I have another concern on a similar topic.
> 
> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
> of 32. Only the internal PPI are between 0 and 31.
> 
> For the moment we add 32 to every SoC interrupts in the irq.h
> define, but I'm assuming that this offset calculation should be done
> thanks to a dedicated irq domain for the SPI.
> The real HW physical number start at 0, and thus this is that value
> that should be in the irq binding of the device.

Yes.

> So ideally we should have a irq domain for the PPI starting at 0 and
> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
> case, but it looks like the PPI/SPI offset is always 32.

Part of the purpose behind irq_domains is to have a translator
callback that can take care of complex mappings, such as mapping each
of the GIC irq ranges onto the Linux irq space.  Plus, by being based
on the DT irq specifiers and dynamically assigning the linux numbers,
the actual mapping that the kernel chooses to use shouldn't actually
have any relevance.  So whether or not the driver uses an offset is 32
becomes an implementation detail.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
> For now, we express the mapping by putting an interrupt-map in the
> core-tile DT, but this feels inelegant as well as wasteful -- expressing
> "+ 32" using a table which is about 1K in size and duplicates that
> information 43 times.
> 
> Using a dedicated irq domain or a fake interrupt controller node to
> encapsulate the motherboard interrupts feels like a cleaner approach,
> but for now I'm not clear on the best way to do it.

An irq nexus node would indeed be something to investigate for your
particular case.  Look for examples of interrupt-map.  It is most
often used for handling IRQ swizzling on PCI busses.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
> For now, we express the mapping by putting an interrupt-map in the
> core-tile DT, but this feels inelegant as well as wasteful -- expressing
> "+ 32" using a table which is about 1K in size and duplicates that
> information 43 times.
> 
> Using a dedicated irq domain or a fake interrupt controller node to
> encapsulate the motherboard interrupts feels like a cleaner approach,
> but for now I'm not clear on the best way to do it.

An irq nexus node would indeed be something to investigate for your
particular case.  Look for examples of interrupt-map.  It is most
often used for handling IRQ swizzling on PCI busses.

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
> For now, we express the mapping by putting an interrupt-map in the
> core-tile DT, but this feels inelegant as well as wasteful -- expressing
> "+ 32" using a table which is about 1K in size and duplicates that
> information 43 times.
> 
> Using a dedicated irq domain or a fake interrupt controller node to
> encapsulate the motherboard interrupts feels like a cleaner approach,
> but for now I'm not clear on the best way to do it.

An irq nexus node would indeed be something to investigate for your
particular case.  Look for examples of interrupt-map.  It is most
often used for handling IRQ swizzling on PCI busses.

g.

Re: [PATCH 4/5] ARM: gic: allow irq_start to be 0

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:39AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> There's really no need to set irq_start per platform for the primary gic.
> The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
> setup doesn't really matter. So allow irq_start to be set to 0 to match
> the linux irq numbering.

Is this really what you want?  Linux irq 0 is not supposed to be used.
With the transition to dynamically allocated irq_descs, I want to make
sure 0 never gets assigned.

g.

> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  arch/arm/common/gic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 666b278..d1ccc72 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -359,7 +359,7 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
>  	gic = &gic_data[gic_nr];
>  	gic->dist_base = dist_base;
>  	gic->cpu_base = cpu_base;
> -	gic->irq_offset = (irq_start - 1) & ~31;
> +	gic->irq_offset = irq_start ? (irq_start - 1) & ~31 : 0;
>  
>  	if (gic_nr == 0)
>  		gic_cpu_base_addr = cpu_base;
> -- 
> 1.7.5.4
> 

Re: [PATCH 4/5] ARM: gic: allow irq_start to be 0

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:39AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> There's really no need to set irq_start per platform for the primary gic.
> The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
> setup doesn't really matter. So allow irq_start to be set to 0 to match
> the linux irq numbering.

Is this really what you want?  Linux irq 0 is not supposed to be used.
With the transition to dynamically allocated irq_descs, I want to make
sure 0 never gets assigned.

g.

> 
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> ---
>  arch/arm/common/gic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 666b278..d1ccc72 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -359,7 +359,7 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
>  	gic = &gic_data[gic_nr];
>  	gic->dist_base = dist_base;
>  	gic->cpu_base = cpu_base;
> -	gic->irq_offset = (irq_start - 1) & ~31;
> +	gic->irq_offset = irq_start ? (irq_start - 1) & ~31 : 0;
>  
>  	if (gic_nr == 0)
>  		gic_cpu_base_addr = cpu_base;
> -- 
> 1.7.5.4
> 

[PATCH 4/5] ARM: gic: allow irq_start to be 0

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:39AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> There's really no need to set irq_start per platform for the primary gic.
> The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
> setup doesn't really matter. So allow irq_start to be set to 0 to match
> the linux irq numbering.

Is this really what you want?  Linux irq 0 is not supposed to be used.
With the transition to dynamically allocated irq_descs, I want to make
sure 0 never gets assigned.

g.

> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  arch/arm/common/gic.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
> index 666b278..d1ccc72 100644
> --- a/arch/arm/common/gic.c
> +++ b/arch/arm/common/gic.c
> @@ -359,7 +359,7 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
>  	gic = &gic_data[gic_nr];
>  	gic->dist_base = dist_base;
>  	gic->cpu_base = cpu_base;
> -	gic->irq_offset = (irq_start - 1) & ~31;
> +	gic->irq_offset = irq_start ? (irq_start - 1) & ~31 : 0;
>  
>  	if (gic_nr == 0)
>  		gic_cpu_base_addr = cpu_base;
> -- 
> 1.7.5.4
> 

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:40AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..6c513de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,53 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> +	"arm,cortex-a9-gic"
> +	"arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> +
> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> +  for PPIs.
> +
> +  The 2nd cell is the level-sense information, encoded as follows:
> +                    1 = low-to-high edge triggered
> +                    2 = high-to-low edge triggered
> +                    4 = active high level-sensitive
> +                    8 = active low level-sensitive
> +
> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> +
> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> +  be 0 for PPIs.

THe binding looks good, but I really think the first cell should be
the mask; followed by the irq number in the 2nd and the flags in the
3rd.  That would better match with existing practice.

> +
> +- reg : Specifies base physical address(s) and size of the GIC registers. The
> +  first 2 values are the GIC distributor register base and size. The 2nd 2

... first region is the GIC distributor...

... The 2nd region is the GIC cpu ...


I've only looked at the code changes superficially, but it looks good
to me.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:40AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..6c513de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,53 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> +	"arm,cortex-a9-gic"
> +	"arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> +
> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> +  for PPIs.
> +
> +  The 2nd cell is the level-sense information, encoded as follows:
> +                    1 = low-to-high edge triggered
> +                    2 = high-to-low edge triggered
> +                    4 = active high level-sensitive
> +                    8 = active low level-sensitive
> +
> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> +
> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> +  be 0 for PPIs.

THe binding looks good, but I really think the first cell should be
the mask; followed by the irq number in the 2nd and the flags in the
3rd.  That would better match with existing practice.

> +
> +- reg : Specifies base physical address(s) and size of the GIC registers. The
> +  first 2 values are the GIC distributor register base and size. The 2nd 2

... first region is the GIC distributor...

... The 2nd region is the GIC cpu ...


I've only looked at the code changes superficially, but it looks good
to me.

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Wed, Sep 14, 2011 at 11:31:40AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> This adds gic initialization using device tree data. The initialization
> functions are intended to be called by a generic OF interrupt
> controller parsing function once the right pieces are in place.
> 
> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
> mask the PPI is assigned to.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
> ---
>  Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>  arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>  arch/arm/include/asm/hardware/gic.h           |   10 +++++
>  3 files changed, 114 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
> new file mode 100644
> index 0000000..6c513de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -0,0 +1,53 @@
> +* ARM Generic Interrupt Controller
> +
> +ARM SMP cores are often associated with a GIC, providing per processor
> +interrupts (PPI), shared processor interrupts (SPI) and software
> +generated interrupts (SGI).
> +
> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> +Secondary GICs are cascaded into the upward interrupt controller and do not
> +have PPIs or SGIs.
> +
> +Main node required properties:
> +
> +- compatible : should be one of:
> +	"arm,cortex-a9-gic"
> +	"arm,arm11mp-gic"
> +- interrupt-controller : Identifies the node as an interrupt controller
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> +  interrupt source.  The type shall be a <u32> and the value shall be 3.
> +
> +  The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
> +  for PPIs.
> +
> +  The 2nd cell is the level-sense information, encoded as follows:
> +                    1 = low-to-high edge triggered
> +                    2 = high-to-low edge triggered
> +                    4 = active high level-sensitive
> +                    8 = active low level-sensitive
> +
> +  Only values of 1 and 4 are valid for GIC 1.0 spec.
> +
> +  The 3rd cell contains the mask of the cpu number for the interrupt source.
> +  The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
> +  be 0 for PPIs.

THe binding looks good, but I really think the first cell should be
the mask; followed by the irq number in the 2nd and the flags in the
3rd.  That would better match with existing practice.

> +
> +- reg : Specifies base physical address(s) and size of the GIC registers. The
> +  first 2 values are the GIC distributor register base and size. The 2nd 2

... first region is the GIC distributor...

... The 2nd region is the GIC cpu ...


I've only looked at the code changes superficially, but it looks good
to me.

g.

Re: [PATCH 4/5] ARM: gic: allow irq_start to be 0

[Russell King - ARM Linux]

On Wed, Sep 14, 2011 at 11:31:39AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> There's really no need to set irq_start per platform for the primary gic.
> The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
> setup doesn't really matter. So allow irq_start to be set to 0 to match
> the linux irq numbering.

That's not correct.  The hardware starts numbering SPI IRQs from 32 when
reading the INTACK register.  The number which gets passed through into
asm_do_IRQ() will therefore be from 32 and above.

There's several reasons for this:
1. To avoid IRQ0, which is commonly used to indicate 'no interrupt' to
   drivers.
2. To avoid the ISA IRQ range 1-15 which are hard-coded into various
   drivers (and we want those to fail.)
3. It's wasteful and pointless to manipulate the IRQ number given that we
   have sparse irq support.

Also, bear in mind that gic_irq(SPI0) needs to return 32 to hit the
right registers - so you'd have to set gic->irq_start to -32 to make
SPI0 = IRQ0 work.

Finally, the valid range for irq_start is 16 to 32 + the Linux IRQ base
for the first GIC (SGI) interrupt.  We should probably make gic_init()
BUG() if its passed values less than 16.

Re: [PATCH 4/5] ARM: gic: allow irq_start to be 0

[Russell King - ARM Linux]

On Wed, Sep 14, 2011 at 11:31:39AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
> 
> There's really no need to set irq_start per platform for the primary gic.
> The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
> setup doesn't really matter. So allow irq_start to be set to 0 to match
> the linux irq numbering.

That's not correct.  The hardware starts numbering SPI IRQs from 32 when
reading the INTACK register.  The number which gets passed through into
asm_do_IRQ() will therefore be from 32 and above.

There's several reasons for this:
1. To avoid IRQ0, which is commonly used to indicate 'no interrupt' to
   drivers.
2. To avoid the ISA IRQ range 1-15 which are hard-coded into various
   drivers (and we want those to fail.)
3. It's wasteful and pointless to manipulate the IRQ number given that we
   have sparse irq support.

Also, bear in mind that gic_irq(SPI0) needs to return 32 to hit the
right registers - so you'd have to set gic->irq_start to -32 to make
SPI0 = IRQ0 work.

Finally, the valid range for irq_start is 16 to 32 + the Linux IRQ base
for the first GIC (SGI) interrupt.  We should probably make gic_init()
BUG() if its passed values less than 16.

[PATCH 4/5] ARM: gic: allow irq_start to be 0

[Russell King - ARM Linux]

On Wed, Sep 14, 2011 at 11:31:39AM -0500, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
> 
> There's really no need to set irq_start per platform for the primary gic.
> The SGIs and PPIs are not handled as normal irqs, so how irqs 0-31 are
> setup doesn't really matter. So allow irq_start to be set to 0 to match
> the linux irq numbering.

That's not correct.  The hardware starts numbering SPI IRQs from 32 when
reading the INTACK register.  The number which gets passed through into
asm_do_IRQ() will therefore be from 32 and above.

There's several reasons for this:
1. To avoid IRQ0, which is commonly used to indicate 'no interrupt' to
   drivers.
2. To avoid the ISA IRQ range 1-15 which are hard-coded into various
   drivers (and we want those to fail.)
3. It's wasteful and pointless to manipulate the IRQ number given that we
   have sparse irq support.

Also, bear in mind that gic_irq(SPI0) needs to return 32 to hit the
right registers - so you'd have to set gic->irq_start to -32 to make
SPI0 = IRQ0 work.

Finally, the valid range for irq_start is 16 to 32 + the Linux IRQ base
for the first GIC (SGI) interrupt.  We should probably make gic_init()
BUG() if its passed values less than 16.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/15/2011 11:43 AM, Rob Herring wrote:
> Benoit,
> 
> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>> Benoit,
>>>
>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>>> Hi Rob,
>>>>
>>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>>
>>>>>> This adds gic initialization using device tree data. The
>>>>>> initialization
>>>>>> functions are intended to be called by a generic OF interrupt
>>>>>> controller parsing function once the right pieces are in place.
>>>>>>
>>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>>> the cpu
>>>>>> mask the PPI is assigned to.
>>>>>>
>>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>>> ---
>>>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>>> ++++++++++++++++++++++++
>>>>>>    arch/arm/common/gic.c                         |   55
>>>>>> +++++++++++++++++++++++--
>>>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>>> index d1ccc72..14de380 100644
>>>>>> --- a/arch/arm/common/gic.c
>>>>>> +++ b/arch/arm/common/gic.c
>>>>>
>>>>> [...]
>>>>>
>>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>>> *parent)
>>>>>> +{
>>>>>> +       void __iomem *cpu_base;
>>>>>> +       void __iomem *dist_base;
>>>>>> +       int irq;
>>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>>> +
>>>>>> +       if (WARN_ON(!node))
>>>>>> +               return;
>>>>>> +
>>>>>> +       dist_base = of_iomap(node, 0);
>>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>>> +
>>>>>> +       cpu_base = of_iomap(node, 1);
>>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>>> +
>>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>>> numa_node_id());
>>>>>
>>>>> For exynos4, all the interrupts originating from GIC are statically
>>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>>> start from 64). In the above code, since irq_base would be 0 for
>>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>>> previous version of the patch, you have given a option to the platform
>>>>> code to choose the offset. Could that option be added to this series
>>>>> also. Or a provision to use platform specific translate function
>>>>> instead of the irq_domain_simple translator.
>>>>
>>>> I have another concern on a similar topic.
>>>>
>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>> 32. Only the internal PPI are between 0 and 31.
>>>>
>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>
>>> Those defines will not be used in the DT case. So the question is
>>> whether to add 32 or not in the DT. Since we have just a single node and
>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>> agreement.
>>
>> This is a agreement inside the MPUSS, but not outside.
>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>> with that today.
>>
>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>> dedicated irq domain for the SPI.
>>>> The real HW physical number start at 0, and thus this is that value that
>>>> should be in the irq binding of the device.
>>>>
>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>
>>>
>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>> controller, It will have 32 reserved interrupts and the register layout
>>> is exactly the same as a cpu's GIC.
>>
>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>> to tweak the HW number provided by the HW spec in order to add that offset.
>> If you look at SoC level, the MPUSS is just an IP that can be
>> potentially replaced by other one that will not have a GIC. In that case
>> you will not change the IRQ mapping at SoC level.
>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>> all the interrupts will have to be shifted by 32 just because the MPU
>> subsystem is different.
>>
> 
> Is that a realistic case? That would be a new chip and new device tree.
> You could argue that the whole peripheral subsystem DT could be reused
> and the numbering needs to be the same. However, there's one thing that
> would prevent that. The number of interrupt cells is defined by the
> controller binding. So you have to change the peripheral nodes anyway.
> 
> It's good that OMAP is trying to standardize the peripheral layout, but
> in my experience that's not something you can rely on.
> 
> At some point the interrupt numbering is going to differ from the h/w
> documentation. If it's not in the DT, then it will be in linux. Right
> now its just offset of 32, but if irqdescs get assigned on demand as PPC
> is doing, then there will be no relationship to the documentation.
> 
>> Since that offset is dependent of the GIC internals and is not exposed
>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>> spec is exposing exactly that.
>>
>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>> with a simple linear translation. Ultimately, domains will do dynamic
>>> irqdesc allocation and the translation within the gic will be completely
>>> dynamic.
>>
>> I think the only reason to do that is to separate internal MPU
>> interrupts with the external ones that should not have a clue about the
>> GIC.
> 
> I see 2 options (besides leaving it as is):
> 
> - Revert back to my previous binding where PPIs are a sub-node and a
> different interrupt parent.
> 
> - Use the current binding, but allow SPIs to start at 0. We can still
> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> not be able to with this scheme.
> 
> Either way you will still have the above issue with the cell size changing.
> 

I was headed down the path of implementing the 2nd option above, but had
a dilemma. What would be the numbering base for PPIs in this case?
Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
Numbering PPIs at 0 will just cause confusion as will numbering
differently from SPIs. There is absolutely no mention of SPI0 or SPIx
numbering in the GIC spec. All interrupt number references refer to the
absolute interrupt ID, not a relative number based on the type. The fact
that the Cortex-A9 implementation has interrupt lines numbered equal to
the GIC SPI interrupts is an implementation detail of the A9. Other
cores could have different arrangement including bringing out PPI
interrupts or reserving some SPIs.

As there are many users of the GIC, it makes more sense to align with
the GIC documentation rather than the documentation of 1 SOC. BTW, I
have the exact same issue in our documentation.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/15/2011 11:43 AM, Rob Herring wrote:
> Benoit,
> 
> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>> Benoit,
>>>
>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>>> Hi Rob,
>>>>
>>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>>
>>>>>> This adds gic initialization using device tree data. The
>>>>>> initialization
>>>>>> functions are intended to be called by a generic OF interrupt
>>>>>> controller parsing function once the right pieces are in place.
>>>>>>
>>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>>> the cpu
>>>>>> mask the PPI is assigned to.
>>>>>>
>>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>>> ---
>>>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>>> ++++++++++++++++++++++++
>>>>>>    arch/arm/common/gic.c                         |   55
>>>>>> +++++++++++++++++++++++--
>>>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>>> index d1ccc72..14de380 100644
>>>>>> --- a/arch/arm/common/gic.c
>>>>>> +++ b/arch/arm/common/gic.c
>>>>>
>>>>> [...]
>>>>>
>>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>>> *parent)
>>>>>> +{
>>>>>> +       void __iomem *cpu_base;
>>>>>> +       void __iomem *dist_base;
>>>>>> +       int irq;
>>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>>> +
>>>>>> +       if (WARN_ON(!node))
>>>>>> +               return;
>>>>>> +
>>>>>> +       dist_base = of_iomap(node, 0);
>>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>>> +
>>>>>> +       cpu_base = of_iomap(node, 1);
>>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>>> +
>>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>>> numa_node_id());
>>>>>
>>>>> For exynos4, all the interrupts originating from GIC are statically
>>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>>> start from 64). In the above code, since irq_base would be 0 for
>>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>>> previous version of the patch, you have given a option to the platform
>>>>> code to choose the offset. Could that option be added to this series
>>>>> also. Or a provision to use platform specific translate function
>>>>> instead of the irq_domain_simple translator.
>>>>
>>>> I have another concern on a similar topic.
>>>>
>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>> 32. Only the internal PPI are between 0 and 31.
>>>>
>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>
>>> Those defines will not be used in the DT case. So the question is
>>> whether to add 32 or not in the DT. Since we have just a single node and
>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>> agreement.
>>
>> This is a agreement inside the MPUSS, but not outside.
>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>> with that today.
>>
>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>> dedicated irq domain for the SPI.
>>>> The real HW physical number start at 0, and thus this is that value that
>>>> should be in the irq binding of the device.
>>>>
>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>
>>>
>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>> controller, It will have 32 reserved interrupts and the register layout
>>> is exactly the same as a cpu's GIC.
>>
>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>> to tweak the HW number provided by the HW spec in order to add that offset.
>> If you look at SoC level, the MPUSS is just an IP that can be
>> potentially replaced by other one that will not have a GIC. In that case
>> you will not change the IRQ mapping at SoC level.
>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>> all the interrupts will have to be shifted by 32 just because the MPU
>> subsystem is different.
>>
> 
> Is that a realistic case? That would be a new chip and new device tree.
> You could argue that the whole peripheral subsystem DT could be reused
> and the numbering needs to be the same. However, there's one thing that
> would prevent that. The number of interrupt cells is defined by the
> controller binding. So you have to change the peripheral nodes anyway.
> 
> It's good that OMAP is trying to standardize the peripheral layout, but
> in my experience that's not something you can rely on.
> 
> At some point the interrupt numbering is going to differ from the h/w
> documentation. If it's not in the DT, then it will be in linux. Right
> now its just offset of 32, but if irqdescs get assigned on demand as PPC
> is doing, then there will be no relationship to the documentation.
> 
>> Since that offset is dependent of the GIC internals and is not exposed
>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>> spec is exposing exactly that.
>>
>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>> with a simple linear translation. Ultimately, domains will do dynamic
>>> irqdesc allocation and the translation within the gic will be completely
>>> dynamic.
>>
>> I think the only reason to do that is to separate internal MPU
>> interrupts with the external ones that should not have a clue about the
>> GIC.
> 
> I see 2 options (besides leaving it as is):
> 
> - Revert back to my previous binding where PPIs are a sub-node and a
> different interrupt parent.
> 
> - Use the current binding, but allow SPIs to start at 0. We can still
> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> not be able to with this scheme.
> 
> Either way you will still have the above issue with the cell size changing.
> 

I was headed down the path of implementing the 2nd option above, but had
a dilemma. What would be the numbering base for PPIs in this case?
Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
Numbering PPIs at 0 will just cause confusion as will numbering
differently from SPIs. There is absolutely no mention of SPI0 or SPIx
numbering in the GIC spec. All interrupt number references refer to the
absolute interrupt ID, not a relative number based on the type. The fact
that the Cortex-A9 implementation has interrupt lines numbered equal to
the GIC SPI interrupts is an implementation detail of the A9. Other
cores could have different arrangement including bringing out PPI
interrupts or reserving some SPIs.

As there are many users of the GIC, it makes more sense to align with
the GIC documentation rather than the documentation of 1 SOC. BTW, I
have the exact same issue in our documentation.

Rob

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/15/2011 11:43 AM, Rob Herring wrote:
> Benoit,
> 
> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>> Benoit,
>>>
>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>>> Hi Rob,
>>>>
>>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>>
>>>>>> This adds gic initialization using device tree data. The
>>>>>> initialization
>>>>>> functions are intended to be called by a generic OF interrupt
>>>>>> controller parsing function once the right pieces are in place.
>>>>>>
>>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>>> the cpu
>>>>>> mask the PPI is assigned to.
>>>>>>
>>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>>> ---
>>>>>>    Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>>> ++++++++++++++++++++++++
>>>>>>    arch/arm/common/gic.c                         |   55
>>>>>> +++++++++++++++++++++++--
>>>>>>    arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>>    3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>>    create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>>> index d1ccc72..14de380 100644
>>>>>> --- a/arch/arm/common/gic.c
>>>>>> +++ b/arch/arm/common/gic.c
>>>>>
>>>>> [...]
>>>>>
>>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>>> *parent)
>>>>>> +{
>>>>>> +       void __iomem *cpu_base;
>>>>>> +       void __iomem *dist_base;
>>>>>> +       int irq;
>>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>>> +
>>>>>> +       if (WARN_ON(!node))
>>>>>> +               return;
>>>>>> +
>>>>>> +       dist_base = of_iomap(node, 0);
>>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>>> +
>>>>>> +       cpu_base = of_iomap(node, 1);
>>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>>> +
>>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>>> numa_node_id());
>>>>>
>>>>> For exynos4, all the interrupts originating from GIC are statically
>>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>>> start from 64). In the above code, since irq_base would be 0 for
>>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>>> previous version of the patch, you have given a option to the platform
>>>>> code to choose the offset. Could that option be added to this series
>>>>> also. Or a provision to use platform specific translate function
>>>>> instead of the irq_domain_simple translator.
>>>>
>>>> I have another concern on a similar topic.
>>>>
>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>> 32. Only the internal PPI are between 0 and 31.
>>>>
>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>
>>> Those defines will not be used in the DT case. So the question is
>>> whether to add 32 or not in the DT. Since we have just a single node and
>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>> agreement.
>>
>> This is a agreement inside the MPUSS, but not outside.
>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>> with that today.
>>
>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>> dedicated irq domain for the SPI.
>>>> The real HW physical number start at 0, and thus this is that value that
>>>> should be in the irq binding of the device.
>>>>
>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>
>>>
>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>> controller, It will have 32 reserved interrupts and the register layout
>>> is exactly the same as a cpu's GIC.
>>
>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>> to tweak the HW number provided by the HW spec in order to add that offset.
>> If you look at SoC level, the MPUSS is just an IP that can be
>> potentially replaced by other one that will not have a GIC. In that case
>> you will not change the IRQ mapping at SoC level.
>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>> all the interrupts will have to be shifted by 32 just because the MPU
>> subsystem is different.
>>
> 
> Is that a realistic case? That would be a new chip and new device tree.
> You could argue that the whole peripheral subsystem DT could be reused
> and the numbering needs to be the same. However, there's one thing that
> would prevent that. The number of interrupt cells is defined by the
> controller binding. So you have to change the peripheral nodes anyway.
> 
> It's good that OMAP is trying to standardize the peripheral layout, but
> in my experience that's not something you can rely on.
> 
> At some point the interrupt numbering is going to differ from the h/w
> documentation. If it's not in the DT, then it will be in linux. Right
> now its just offset of 32, but if irqdescs get assigned on demand as PPC
> is doing, then there will be no relationship to the documentation.
> 
>> Since that offset is dependent of the GIC internals and is not exposed
>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>> spec is exposing exactly that.
>>
>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>> with a simple linear translation. Ultimately, domains will do dynamic
>>> irqdesc allocation and the translation within the gic will be completely
>>> dynamic.
>>
>> I think the only reason to do that is to separate internal MPU
>> interrupts with the external ones that should not have a clue about the
>> GIC.
> 
> I see 2 options (besides leaving it as is):
> 
> - Revert back to my previous binding where PPIs are a sub-node and a
> different interrupt parent.
> 
> - Use the current binding, but allow SPIs to start at 0. We can still
> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> not be able to with this scheme.
> 
> Either way you will still have the above issue with the cell size changing.
> 

I was headed down the path of implementing the 2nd option above, but had
a dilemma. What would be the numbering base for PPIs in this case?
Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
Numbering PPIs at 0 will just cause confusion as will numbering
differently from SPIs. There is absolutely no mention of SPI0 or SPIx
numbering in the GIC spec. All interrupt number references refer to the
absolute interrupt ID, not a relative number based on the type. The fact
that the Cortex-A9 implementation has interrupt lines numbered equal to
the GIC SPI interrupts is an implementation detail of the A9. Other
cores could have different arrangement including bringing out PPI
interrupts or reserving some SPIs.

As there are many users of the GIC, it makes more sense to align with
the GIC documentation rather than the documentation of 1 SOC. BTW, I
have the exact same issue in our documentation.

Rob

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/18/2011 8:15 AM, Grant Likely wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>>   arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>>>> +{
>>>> +       void __iomem *cpu_base;
>>>> +       void __iomem *dist_base;
>>>> +       int irq;
>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> +       if (WARN_ON(!node))
>>>> +               return;
>>>> +
>>>> +       dist_base = of_iomap(node, 0);
>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> +       cpu_base = of_iomap(node, 1);
>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
>> of 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h
>> define, but I'm assuming that this offset calculation should be done
>> thanks to a dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value
>> that should be in the irq binding of the device.
>
> Yes.
>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>
> Part of the purpose behind irq_domains is to have a translator
> callback that can take care of complex mappings, such as mapping each
> of the GIC irq ranges onto the Linux irq space.  Plus, by being based
> on the DT irq specifiers and dynamically assigning the linux numbers,
> the actual mapping that the kernel chooses to use shouldn't actually
> have any relevance.  So whether or not the driver uses an offset is 32
> becomes an implementation detail.

I do agree, my point was not about the driver usage but about how the 
device node should populate its irq entry. The +32 offset is due to the 
internal implementation of the GIC. That should not be exposed outside 
the MPUSS.

Here are the first IRQs from the OMAP4430 public TRM.

MA_IRQ_0 L2_CACHE_IRQ CORTEXA9 L2 cache controller interrupt
MA_IRQ_1 CTI_IRQ_0 CORTEXA9 Cross-trigger module 0 (CTI0) interrupt
MA_IRQ_2 CTI_IRQ_1 CORTEXA9 Cross-trigger module 1 (CTI1) interrupt
MA_IRQ_3 Reserved Reserved Reserved
MA_IRQ_4 ELM_IRQ ELM Error location process completion
MA_IRQ_5 Reserved Reserved Reserved
MA_IRQ_6 Reserved Reserved Reserved
MA_IRQ_7 sys_nirq1 External External interrupt 1 (active low)
MA_IRQ_8 Reserved Reserved Reserved
MA_IRQ_9 L3_DBG_IRQ L3 L3 interconnect debug error
MA_IRQ_10 L3_APP_IRQ L3 L3 interconnect application error
MA_IRQ_11 PRCM_MPU_IRQ PRCM PRCM interrupt
...

It is a 0 based index, and thus this is the value I'm expecting to enter 
in the irq attribute of the DT node.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/18/2011 8:15 AM, Grant Likely wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>   wrote:
>>>> From: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>> ---
>>>>   Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>>   arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>>>> +{
>>>> +       void __iomem *cpu_base;
>>>> +       void __iomem *dist_base;
>>>> +       int irq;
>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> +       if (WARN_ON(!node))
>>>> +               return;
>>>> +
>>>> +       dist_base = of_iomap(node, 0);
>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> +       cpu_base = of_iomap(node, 1);
>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
>> of 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h
>> define, but I'm assuming that this offset calculation should be done
>> thanks to a dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value
>> that should be in the irq binding of the device.
>
> Yes.
>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>
> Part of the purpose behind irq_domains is to have a translator
> callback that can take care of complex mappings, such as mapping each
> of the GIC irq ranges onto the Linux irq space.  Plus, by being based
> on the DT irq specifiers and dynamically assigning the linux numbers,
> the actual mapping that the kernel chooses to use shouldn't actually
> have any relevance.  So whether or not the driver uses an offset is 32
> becomes an implementation detail.

I do agree, my point was not about the driver usage but about how the 
device node should populate its irq entry. The +32 offset is due to the 
internal implementation of the GIC. That should not be exposed outside 
the MPUSS.

Here are the first IRQs from the OMAP4430 public TRM.

MA_IRQ_0 L2_CACHE_IRQ CORTEXA9 L2 cache controller interrupt
MA_IRQ_1 CTI_IRQ_0 CORTEXA9 Cross-trigger module 0 (CTI0) interrupt
MA_IRQ_2 CTI_IRQ_1 CORTEXA9 Cross-trigger module 1 (CTI1) interrupt
MA_IRQ_3 Reserved Reserved Reserved
MA_IRQ_4 ELM_IRQ ELM Error location process completion
MA_IRQ_5 Reserved Reserved Reserved
MA_IRQ_6 Reserved Reserved Reserved
MA_IRQ_7 sys_nirq1 External External interrupt 1 (active low)
MA_IRQ_8 Reserved Reserved Reserved
MA_IRQ_9 L3_DBG_IRQ L3 L3 interconnect debug error
MA_IRQ_10 L3_APP_IRQ L3 L3 interconnect application error
MA_IRQ_11 PRCM_MPU_IRQ PRCM PRCM interrupt
...

It is a 0 based index, and thus this is the value I'm expecting to enter 
in the irq attribute of the DT node.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/18/2011 8:15 AM, Grant Likely wrote:
> On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
>> Hi Rob,
>>
>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>> Hi Rob,
>>>
>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>   wrote:
>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>> ---
>>>>   Documentation/devicetree/bindings/arm/gic.txt |   53 ++++++++++++++++++++++++
>>>>   arch/arm/common/gic.c                         |   55 +++++++++++++++++++++++--
>>>>   arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>   3 files changed, 114 insertions(+), 4 deletions(-)
>>>>   create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> [...]
>>>
>>>
>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>> index d1ccc72..14de380 100644
>>>> --- a/arch/arm/common/gic.c
>>>> +++ b/arch/arm/common/gic.c
>>>
>>> [...]
>>>
>>>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>>>> +{
>>>> +       void __iomem *cpu_base;
>>>> +       void __iomem *dist_base;
>>>> +       int irq;
>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>> +
>>>> +       if (WARN_ON(!node))
>>>> +               return;
>>>> +
>>>> +       dist_base = of_iomap(node, 0);
>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>> +
>>>> +       cpu_base = of_iomap(node, 1);
>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>> +
>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>>>
>>> For exynos4, all the interrupts originating from GIC are statically
>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>> start from 64). In the above code, since irq_base would be 0 for
>>> exynos4, the interrupt mapping is not working correctly. In your
>>> previous version of the patch, you have given a option to the platform
>>> code to choose the offset. Could that option be added to this series
>>> also. Or a provision to use platform specific translate function
>>> instead of the irq_domain_simple translator.
>>
>> I have another concern on a similar topic.
>>
>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset
>> of 32. Only the internal PPI are between 0 and 31.
>>
>> For the moment we add 32 to every SoC interrupts in the irq.h
>> define, but I'm assuming that this offset calculation should be done
>> thanks to a dedicated irq domain for the SPI.
>> The real HW physical number start at 0, and thus this is that value
>> that should be in the irq binding of the device.
>
> Yes.
>
>> So ideally we should have a irq domain for the PPI starting at 0 and
>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>> case, but it looks like the PPI/SPI offset is always 32.
>
> Part of the purpose behind irq_domains is to have a translator
> callback that can take care of complex mappings, such as mapping each
> of the GIC irq ranges onto the Linux irq space.  Plus, by being based
> on the DT irq specifiers and dynamically assigning the linux numbers,
> the actual mapping that the kernel chooses to use shouldn't actually
> have any relevance.  So whether or not the driver uses an offset is 32
> becomes an implementation detail.

I do agree, my point was not about the driver usage but about how the 
device node should populate its irq entry. The +32 offset is due to the 
internal implementation of the GIC. That should not be exposed outside 
the MPUSS.

Here are the first IRQs from the OMAP4430 public TRM.

MA_IRQ_0 L2_CACHE_IRQ CORTEXA9 L2 cache controller interrupt
MA_IRQ_1 CTI_IRQ_0 CORTEXA9 Cross-trigger module 0 (CTI0) interrupt
MA_IRQ_2 CTI_IRQ_1 CORTEXA9 Cross-trigger module 1 (CTI1) interrupt
MA_IRQ_3 Reserved Reserved Reserved
MA_IRQ_4 ELM_IRQ ELM Error location process completion
MA_IRQ_5 Reserved Reserved Reserved
MA_IRQ_6 Reserved Reserved Reserved
MA_IRQ_7 sys_nirq1 External External interrupt 1 (active low)
MA_IRQ_8 Reserved Reserved Reserved
MA_IRQ_9 L3_DBG_IRQ L3 L3 interconnect debug error
MA_IRQ_10 L3_APP_IRQ L3 L3 interconnect application error
MA_IRQ_11 PRCM_MPU_IRQ PRCM PRCM interrupt
...

It is a 0 based index, and thus this is the value I'm expecting to enter 
in the irq attribute of the DT node.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 6:43 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>> Benoit,
>>>
>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>>> Hi Rob,
>>>>
>>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>    wrote:
>>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>>
>>>>>> This adds gic initialization using device tree data. The
>>>>>> initialization
>>>>>> functions are intended to be called by a generic OF interrupt
>>>>>> controller parsing function once the right pieces are in place.
>>>>>>
>>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>>> the cpu
>>>>>> mask the PPI is assigned to.
>>>>>>
>>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>>> ---
>>>>>>     Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>>> ++++++++++++++++++++++++
>>>>>>     arch/arm/common/gic.c                         |   55
>>>>>> +++++++++++++++++++++++--
>>>>>>     arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>>     3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>>> index d1ccc72..14de380 100644
>>>>>> --- a/arch/arm/common/gic.c
>>>>>> +++ b/arch/arm/common/gic.c
>>>>>
>>>>> [...]
>>>>>
>>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>>> *parent)
>>>>>> +{
>>>>>> +       void __iomem *cpu_base;
>>>>>> +       void __iomem *dist_base;
>>>>>> +       int irq;
>>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>>> +
>>>>>> +       if (WARN_ON(!node))
>>>>>> +               return;
>>>>>> +
>>>>>> +       dist_base = of_iomap(node, 0);
>>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>>> +
>>>>>> +       cpu_base = of_iomap(node, 1);
>>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>>> +
>>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>>> numa_node_id());
>>>>>
>>>>> For exynos4, all the interrupts originating from GIC are statically
>>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>>> start from 64). In the above code, since irq_base would be 0 for
>>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>>> previous version of the patch, you have given a option to the platform
>>>>> code to choose the offset. Could that option be added to this series
>>>>> also. Or a provision to use platform specific translate function
>>>>> instead of the irq_domain_simple translator.
>>>>
>>>> I have another concern on a similar topic.
>>>>
>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>> 32. Only the internal PPI are between 0 and 31.
>>>>
>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>
>>> Those defines will not be used in the DT case. So the question is
>>> whether to add 32 or not in the DT. Since we have just a single node and
>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>> agreement.
>>
>> This is a agreement inside the MPUSS, but not outside.
>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>> with that today.
>>
>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>> dedicated irq domain for the SPI.
>>>> The real HW physical number start at 0, and thus this is that value that
>>>> should be in the irq binding of the device.
>>>>
>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>
>>>
>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>> controller, It will have 32 reserved interrupts and the register layout
>>> is exactly the same as a cpu's GIC.
>>
>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>> to tweak the HW number provided by the HW spec in order to add that offset.
>> If you look at SoC level, the MPUSS is just an IP that can be
>> potentially replaced by other one that will not have a GIC. In that case
>> you will not change the IRQ mapping at SoC level.
>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>> all the interrupts will have to be shifted by 32 just because the MPU
>> subsystem is different.
>>
>
> Is that a realistic case? That would be a new chip and new device tree.
> You could argue that the whole peripheral subsystem DT could be reused
> and the numbering needs to be the same.

Yes, it is. I do agree that since we are adding a bunch of new IPs at 
the same time, it will be hard to keep the exact same definition, but 
the OMAP4 irq table is reusing most of OMAP3 definition.

> However, there's one thing that
> would prevent that. The number of interrupt cells is defined by the
> controller binding. So you have to change the peripheral nodes anyway.

I think that might be avoided by using a generic irq controller name 
alias like &intc.

> It's good that OMAP is trying to standardize the peripheral layout, but
> in my experience that's not something you can rely on.
>
> At some point the interrupt numbering is going to differ from the h/w
> documentation. If it's not in the DT, then it will be in linux. Right
> now its just offset of 32, but if irqdescs get assigned on demand as PPC
> is doing, then there will be no relationship to the documentation.

Yes, but this is the whole point, that's why the DT irq number should 
stick to the HW documentation, not to the underlying irq controller 
implementation.

The MPUSS is an IP like any other IPs in a SoC, and at the boundary of 
that IP, only 128 IRQ lines are exposed, hence the numbering scheme from 
0 to 127.

>> Since that offset is dependent of the GIC internals and is not exposed
>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>> spec is exposing exactly that.
>>
>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>> with a simple linear translation. Ultimately, domains will do dynamic
>>> irqdesc allocation and the translation within the gic will be completely
>>> dynamic.
>>
>> I think the only reason to do that is to separate internal MPU
>> interrupts with the external ones that should not have a clue about the
>> GIC.
>
> I see 2 options (besides leaving it as is):
>
> - Revert back to my previous binding where PPIs are a sub-node and a
> different interrupt parent.
>
> - Use the current binding, but allow SPIs to start at 0. We can still
> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> not be able to with this scheme.
>
> Either way you will still have the above issue with the cell size changing.

Since the cpumask is not relevant for the SPI, maybe having two 
interrupt controllers will be more relevant. Or maybe 3, since there is 
some SGIs as well.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 6:43 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>> Benoit,
>>>
>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>>> Hi Rob,
>>>>
>>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 14 September 2011 22:01, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>    wrote:
>>>>>> From: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>>>>
>>>>>> This adds gic initialization using device tree data. The
>>>>>> initialization
>>>>>> functions are intended to be called by a generic OF interrupt
>>>>>> controller parsing function once the right pieces are in place.
>>>>>>
>>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>>> the cpu
>>>>>> mask the PPI is assigned to.
>>>>>>
>>>>>> Signed-off-by: Rob Herring<rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
>>>>>> ---
>>>>>>     Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>>> ++++++++++++++++++++++++
>>>>>>     arch/arm/common/gic.c                         |   55
>>>>>> +++++++++++++++++++++++--
>>>>>>     arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>>     3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>>> index d1ccc72..14de380 100644
>>>>>> --- a/arch/arm/common/gic.c
>>>>>> +++ b/arch/arm/common/gic.c
>>>>>
>>>>> [...]
>>>>>
>>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>>> *parent)
>>>>>> +{
>>>>>> +       void __iomem *cpu_base;
>>>>>> +       void __iomem *dist_base;
>>>>>> +       int irq;
>>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>>> +
>>>>>> +       if (WARN_ON(!node))
>>>>>> +               return;
>>>>>> +
>>>>>> +       dist_base = of_iomap(node, 0);
>>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>>> +
>>>>>> +       cpu_base = of_iomap(node, 1);
>>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>>> +
>>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>>> numa_node_id());
>>>>>
>>>>> For exynos4, all the interrupts originating from GIC are statically
>>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>>> start from 64). In the above code, since irq_base would be 0 for
>>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>>> previous version of the patch, you have given a option to the platform
>>>>> code to choose the offset. Could that option be added to this series
>>>>> also. Or a provision to use platform specific translate function
>>>>> instead of the irq_domain_simple translator.
>>>>
>>>> I have another concern on a similar topic.
>>>>
>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>> 32. Only the internal PPI are between 0 and 31.
>>>>
>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>
>>> Those defines will not be used in the DT case. So the question is
>>> whether to add 32 or not in the DT. Since we have just a single node and
>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>> agreement.
>>
>> This is a agreement inside the MPUSS, but not outside.
>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>> with that today.
>>
>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>> dedicated irq domain for the SPI.
>>>> The real HW physical number start at 0, and thus this is that value that
>>>> should be in the irq binding of the device.
>>>>
>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>
>>>
>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>> controller, It will have 32 reserved interrupts and the register layout
>>> is exactly the same as a cpu's GIC.
>>
>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>> to tweak the HW number provided by the HW spec in order to add that offset.
>> If you look at SoC level, the MPUSS is just an IP that can be
>> potentially replaced by other one that will not have a GIC. In that case
>> you will not change the IRQ mapping at SoC level.
>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>> all the interrupts will have to be shifted by 32 just because the MPU
>> subsystem is different.
>>
>
> Is that a realistic case? That would be a new chip and new device tree.
> You could argue that the whole peripheral subsystem DT could be reused
> and the numbering needs to be the same.

Yes, it is. I do agree that since we are adding a bunch of new IPs at 
the same time, it will be hard to keep the exact same definition, but 
the OMAP4 irq table is reusing most of OMAP3 definition.

> However, there's one thing that
> would prevent that. The number of interrupt cells is defined by the
> controller binding. So you have to change the peripheral nodes anyway.

I think that might be avoided by using a generic irq controller name 
alias like &intc.

> It's good that OMAP is trying to standardize the peripheral layout, but
> in my experience that's not something you can rely on.
>
> At some point the interrupt numbering is going to differ from the h/w
> documentation. If it's not in the DT, then it will be in linux. Right
> now its just offset of 32, but if irqdescs get assigned on demand as PPC
> is doing, then there will be no relationship to the documentation.

Yes, but this is the whole point, that's why the DT irq number should 
stick to the HW documentation, not to the underlying irq controller 
implementation.

The MPUSS is an IP like any other IPs in a SoC, and at the boundary of 
that IP, only 128 IRQ lines are exposed, hence the numbering scheme from 
0 to 127.

>> Since that offset is dependent of the GIC internals and is not exposed
>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>> spec is exposing exactly that.
>>
>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>> with a simple linear translation. Ultimately, domains will do dynamic
>>> irqdesc allocation and the translation within the gic will be completely
>>> dynamic.
>>
>> I think the only reason to do that is to separate internal MPU
>> interrupts with the external ones that should not have a clue about the
>> GIC.
>
> I see 2 options (besides leaving it as is):
>
> - Revert back to my previous binding where PPIs are a sub-node and a
> different interrupt parent.
>
> - Use the current binding, but allow SPIs to start at 0. We can still
> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> not be able to with this scheme.
>
> Either way you will still have the above issue with the cell size changing.

Since the cpumask is not relevant for the SPI, maybe having two 
interrupt controllers will be more relevant. Or maybe 3, since there is 
some SGIs as well.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/15/2011 6:43 PM, Rob Herring wrote:
> Benoit,
>
> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>> Benoit,
>>>
>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>>> Hi Rob,
>>>>
>>>> On 9/15/2011 9:55 AM, Thomas Abraham wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On 14 September 2011 22:01, Rob Herring<robherring2@gmail.com>    wrote:
>>>>>> From: Rob Herring<rob.herring@calxeda.com>
>>>>>>
>>>>>> This adds gic initialization using device tree data. The
>>>>>> initialization
>>>>>> functions are intended to be called by a generic OF interrupt
>>>>>> controller parsing function once the right pieces are in place.
>>>>>>
>>>>>> PPIs are handled using 3rd cell of interrupts properties to specify
>>>>>> the cpu
>>>>>> mask the PPI is assigned to.
>>>>>>
>>>>>> Signed-off-by: Rob Herring<rob.herring@calxeda.com>
>>>>>> ---
>>>>>>     Documentation/devicetree/bindings/arm/gic.txt |   53
>>>>>> ++++++++++++++++++++++++
>>>>>>     arch/arm/common/gic.c                         |   55
>>>>>> +++++++++++++++++++++++--
>>>>>>     arch/arm/include/asm/hardware/gic.h           |   10 +++++
>>>>>>     3 files changed, 114 insertions(+), 4 deletions(-)
>>>>>>     create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> [...]
>>>>>
>>>>>
>>>>>> diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
>>>>>> index d1ccc72..14de380 100644
>>>>>> --- a/arch/arm/common/gic.c
>>>>>> +++ b/arch/arm/common/gic.c
>>>>>
>>>>> [...]
>>>>>
>>>>>> +void __init gic_of_init(struct device_node *node, struct device_node
>>>>>> *parent)
>>>>>> +{
>>>>>> +       void __iomem *cpu_base;
>>>>>> +       void __iomem *dist_base;
>>>>>> +       int irq;
>>>>>> +       struct irq_domain *domain =&gic_data[gic_cnt].domain;
>>>>>> +
>>>>>> +       if (WARN_ON(!node))
>>>>>> +               return;
>>>>>> +
>>>>>> +       dist_base = of_iomap(node, 0);
>>>>>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>>>>>> +
>>>>>> +       cpu_base = of_iomap(node, 1);
>>>>>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>>>>>> +
>>>>>> +       domain->nr_irq = gic_irq_count(dist_base);
>>>>>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq,
>>>>>> numa_node_id());
>>>>>
>>>>> For exynos4, all the interrupts originating from GIC are statically
>>>>> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>>>>> start from 64). In the above code, since irq_base would be 0 for
>>>>> exynos4, the interrupt mapping is not working correctly. In your
>>>>> previous version of the patch, you have given a option to the platform
>>>>> code to choose the offset. Could that option be added to this series
>>>>> also. Or a provision to use platform specific translate function
>>>>> instead of the irq_domain_simple translator.
>>>>
>>>> I have another concern on a similar topic.
>>>>
>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>> 32. Only the internal PPI are between 0 and 31.
>>>>
>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>
>>> Those defines will not be used in the DT case. So the question is
>>> whether to add 32 or not in the DT. Since we have just a single node and
>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>> agreement.
>>
>> This is a agreement inside the MPUSS, but not outside.
>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>> with that today.
>>
>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>> dedicated irq domain for the SPI.
>>>> The real HW physical number start at 0, and thus this is that value that
>>>> should be in the irq binding of the device.
>>>>
>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>
>>>
>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>> controller, It will have 32 reserved interrupts and the register layout
>>> is exactly the same as a cpu's GIC.
>>
>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>> to tweak the HW number provided by the HW spec in order to add that offset.
>> If you look at SoC level, the MPUSS is just an IP that can be
>> potentially replaced by other one that will not have a GIC. In that case
>> you will not change the IRQ mapping at SoC level.
>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>> all the interrupts will have to be shifted by 32 just because the MPU
>> subsystem is different.
>>
>
> Is that a realistic case? That would be a new chip and new device tree.
> You could argue that the whole peripheral subsystem DT could be reused
> and the numbering needs to be the same.

Yes, it is. I do agree that since we are adding a bunch of new IPs at 
the same time, it will be hard to keep the exact same definition, but 
the OMAP4 irq table is reusing most of OMAP3 definition.

> However, there's one thing that
> would prevent that. The number of interrupt cells is defined by the
> controller binding. So you have to change the peripheral nodes anyway.

I think that might be avoided by using a generic irq controller name 
alias like &intc.

> It's good that OMAP is trying to standardize the peripheral layout, but
> in my experience that's not something you can rely on.
>
> At some point the interrupt numbering is going to differ from the h/w
> documentation. If it's not in the DT, then it will be in linux. Right
> now its just offset of 32, but if irqdescs get assigned on demand as PPC
> is doing, then there will be no relationship to the documentation.

Yes, but this is the whole point, that's why the DT irq number should 
stick to the HW documentation, not to the underlying irq controller 
implementation.

The MPUSS is an IP like any other IPs in a SoC, and at the boundary of 
that IP, only 128 IRQ lines are exposed, hence the numbering scheme from 
0 to 127.

>> Since that offset is dependent of the GIC internals and is not exposed
>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>> spec is exposing exactly that.
>>
>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>> with a simple linear translation. Ultimately, domains will do dynamic
>>> irqdesc allocation and the translation within the gic will be completely
>>> dynamic.
>>
>> I think the only reason to do that is to separate internal MPU
>> interrupts with the external ones that should not have a clue about the
>> GIC.
>
> I see 2 options (besides leaving it as is):
>
> - Revert back to my previous binding where PPIs are a sub-node and a
> different interrupt parent.
>
> - Use the current binding, but allow SPIs to start at 0. We can still
> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> not be able to with this scheme.
>
> Either way you will still have the above issue with the cell size changing.

Since the cpumask is not relevant for the SPI, maybe having two 
interrupt controllers will be more relevant. Or maybe 3, since there is 
some SGIs as well.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Dave Martin]

On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
>> For now, we express the mapping by putting an interrupt-map in the
>> core-tile DT, but this feels inelegant as well as wasteful -- expressing
>> "+ 32" using a table which is about 1K in size and duplicates that
>> information 43 times.
>>
>> Using a dedicated irq domain or a fake interrupt controller node to
>> encapsulate the motherboard interrupts feels like a cleaner approach,
>> but for now I'm not clear on the best way to do it.
>
> An irq nexus node would indeed be something to investigate for your
> particular case.  Look for examples of interrupt-map.  It is most
> often used for handling IRQ swizzling on PCI busses.

That's what I currently have -- this is logically correct, and it
works; it just feels like a sledgehammer for cracking this particular
nut, because we don't really have 43 independent interrupt mappings
and types.  We have one offset and one type which is applied to all
the interrupts, and this situation is expected to be the same for all
variations of this board, except that offset may change.  I suspect
this situation applies to many platforms -- the number of interrupts
may in general be much larger than the number of independent mappings.

Another way of looking at the problem is that it's difficult to come
up with a one-size-fits-all description of interrupt mappings which is
also efficient.  Requiring a single set of mapping semantics requires
the mappings to be both rather overspecified for most cases, and
flattened into a large, structureless table which may become pretty
large and unwieldy.  If there were 100+ interrupts instead of 43, we'd
really have to be generating the device tree using a script in order
for it to be maintainable (which is not necessarily a problem, but can
be a warning sign)

An alternative approach is to introduce a special interrupt controller
node which serves as the interrupt-parent for the child domain and
maps the interrupts with flexible semantics defined by the node's
bindings; or different kinds of interrupt-map/interrupt-map-mask
properties could be defined.  Bindings could be added as needed to
support different cases -- though really we should only expect to have
a small number at most.  When the interrupt mapping is significantly
complex, using interrupt-map will probably be the best approach
anyway.


This is just a view for discussion.

For now, I'll keep the interrupt-map for VE. since although it feels
inefficient it is at least obviously correct.

Cheers
---Dave

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Dave Martin]

On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
>> For now, we express the mapping by putting an interrupt-map in the
>> core-tile DT, but this feels inelegant as well as wasteful -- expressing
>> "+ 32" using a table which is about 1K in size and duplicates that
>> information 43 times.
>>
>> Using a dedicated irq domain or a fake interrupt controller node to
>> encapsulate the motherboard interrupts feels like a cleaner approach,
>> but for now I'm not clear on the best way to do it.
>
> An irq nexus node would indeed be something to investigate for your
> particular case.  Look for examples of interrupt-map.  It is most
> often used for handling IRQ swizzling on PCI busses.

That's what I currently have -- this is logically correct, and it
works; it just feels like a sledgehammer for cracking this particular
nut, because we don't really have 43 independent interrupt mappings
and types.  We have one offset and one type which is applied to all
the interrupts, and this situation is expected to be the same for all
variations of this board, except that offset may change.  I suspect
this situation applies to many platforms -- the number of interrupts
may in general be much larger than the number of independent mappings.

Another way of looking at the problem is that it's difficult to come
up with a one-size-fits-all description of interrupt mappings which is
also efficient.  Requiring a single set of mapping semantics requires
the mappings to be both rather overspecified for most cases, and
flattened into a large, structureless table which may become pretty
large and unwieldy.  If there were 100+ interrupts instead of 43, we'd
really have to be generating the device tree using a script in order
for it to be maintainable (which is not necessarily a problem, but can
be a warning sign)

An alternative approach is to introduce a special interrupt controller
node which serves as the interrupt-parent for the child domain and
maps the interrupts with flexible semantics defined by the node's
bindings; or different kinds of interrupt-map/interrupt-map-mask
properties could be defined.  Bindings could be added as needed to
support different cases -- though really we should only expect to have
a small number at most.  When the interrupt mapping is significantly
complex, using interrupt-map will probably be the best approach
anyway.


This is just a view for discussion.

For now, I'll keep the interrupt-map for VE. since although it feels
inefficient it is at least obviously correct.

Cheers
---Dave

[PATCH 5/5] ARM: gic: add OF based initialization

[Dave Martin]

On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
>> For now, we express the mapping by putting an interrupt-map in the
>> core-tile DT, but this feels inelegant as well as wasteful -- expressing
>> "+ 32" using a table which is about 1K in size and duplicates that
>> information 43 times.
>>
>> Using a dedicated irq domain or a fake interrupt controller node to
>> encapsulate the motherboard interrupts feels like a cleaner approach,
>> but for now I'm not clear on the best way to do it.
>
> An irq nexus node would indeed be something to investigate for your
> particular case. ?Look for examples of interrupt-map. ?It is most
> often used for handling IRQ swizzling on PCI busses.

That's what I currently have -- this is logically correct, and it
works; it just feels like a sledgehammer for cracking this particular
nut, because we don't really have 43 independent interrupt mappings
and types.  We have one offset and one type which is applied to all
the interrupts, and this situation is expected to be the same for all
variations of this board, except that offset may change.  I suspect
this situation applies to many platforms -- the number of interrupts
may in general be much larger than the number of independent mappings.

Another way of looking at the problem is that it's difficult to come
up with a one-size-fits-all description of interrupt mappings which is
also efficient.  Requiring a single set of mapping semantics requires
the mappings to be both rather overspecified for most cases, and
flattened into a large, structureless table which may become pretty
large and unwieldy.  If there were 100+ interrupts instead of 43, we'd
really have to be generating the device tree using a script in order
for it to be maintainable (which is not necessarily a problem, but can
be a warning sign)

An alternative approach is to introduce a special interrupt controller
node which serves as the interrupt-parent for the child domain and
maps the interrupts with flexible semantics defined by the node's
bindings; or different kinds of interrupt-map/interrupt-map-mask
properties could be defined.  Bindings could be added as needed to
support different cases -- though really we should only expect to have
a small number at most.  When the interrupt mapping is significantly
complex, using interrupt-map will probably be the best approach
anyway.


This is just a view for discussion.

For now, I'll keep the interrupt-map for VE. since although it feels
inefficient it is at least obviously correct.

Cheers
---Dave

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/18/2011 11:23 PM, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:

[...]

>>>>> I have another concern on a similar topic.
>>>>>
>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>>> 32. Only the internal PPI are between 0 and 31.
>>>>>
>>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>>
>>>> Those defines will not be used in the DT case. So the question is
>>>> whether to add 32 or not in the DT. Since we have just a single node and
>>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>>> agreement.
>>>
>>> This is a agreement inside the MPUSS, but not outside.
>>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>>> with that today.
>>>
>>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>>> dedicated irq domain for the SPI.
>>>>> The real HW physical number start at 0, and thus this is that value that
>>>>> should be in the irq binding of the device.
>>>>>
>>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>>
>>>>
>>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>>> controller, It will have 32 reserved interrupts and the register layout
>>>> is exactly the same as a cpu's GIC.
>>>
>>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>>> to tweak the HW number provided by the HW spec in order to add that offset.
>>> If you look at SoC level, the MPUSS is just an IP that can be
>>> potentially replaced by other one that will not have a GIC. In that case
>>> you will not change the IRQ mapping at SoC level.
>>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>>> all the interrupts will have to be shifted by 32 just because the MPU
>>> subsystem is different.
>>>
>>
>> Is that a realistic case? That would be a new chip and new device tree.
>> You could argue that the whole peripheral subsystem DT could be reused
>> and the numbering needs to be the same. However, there's one thing that
>> would prevent that. The number of interrupt cells is defined by the
>> controller binding. So you have to change the peripheral nodes anyway.
>>
>> It's good that OMAP is trying to standardize the peripheral layout, but
>> in my experience that's not something you can rely on.
>>
>> At some point the interrupt numbering is going to differ from the h/w
>> documentation. If it's not in the DT, then it will be in linux. Right
>> now its just offset of 32, but if irqdescs get assigned on demand as PPC
>> is doing, then there will be no relationship to the documentation.
>>
>>> Since that offset is dependent of the GIC internals and is not exposed
>>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>>> spec is exposing exactly that.
>>>
>>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>>> with a simple linear translation. Ultimately, domains will do dynamic
>>>> irqdesc allocation and the translation within the gic will be completely
>>>> dynamic.
>>>
>>> I think the only reason to do that is to separate internal MPU
>>> interrupts with the external ones that should not have a clue about the
>>> GIC.
>>
>> I see 2 options (besides leaving it as is):
>>
>> - Revert back to my previous binding where PPIs are a sub-node and a
>> different interrupt parent.
>>
>> - Use the current binding, but allow SPIs to start at 0. We can still
>> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
>> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
>> not be able to with this scheme.
>>
>> Either way you will still have the above issue with the cell size changing.
>>
> 
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?

Both SGI and PPI are internal to the CortexA9 MP core, and referring to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID# mapping is already documented:
- Private timer, PPI(2) Each Cortex-A9 processor has its own private timers that can generate interrupts, using ID29.
- Watchdog timers, PPI(3) Each Cortex-A9 processor has its own watchdog timers that can generate interrupts, using ID30.

So in that case, it can makes sense to use the ID. But it is interesting to note that the PPI is identified with a 0 based index number.

> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. 

Probably because it is the generic GIC spec that focus on internals stuff only, it not an integration spec that will show how the SPIs are connected to the outside world. But it is clear that the SPIs are identified as 0-XXX lines outside the Cortex MP core.

In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are triggered by events generated on associated interrupt input lines. The Interrupt Controller can support up to 224 interrupt input lines. The interrupt input lines can be configured to be edge sensitive (posedge) or level sensitive (high level).
SPIs start at ID32.

> All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type. The fact
> that the Cortex-A9 implementation has interrupt lines numbered equal to
> the GIC SPI interrupts is an implementation detail of the A9. 

> Other cores could have different arrangement including bringing out PPI
> interrupts or reserving some SPIs.

Absolutely, that's why we should not use that internal GIC convention to capture external IRQ mapping. It you separate the PPI and the SPI controller, you can allow any kind of internal mapping.

> As there are many users of the GIC, it makes more sense to align with
> the GIC documentation rather than the documentation of 1 SOC. BTW, I
> have the exact same issue in our documentation.

It is not about one SoC, this is probably done like that for every other SoCs. I do not have the TRM for the other SoCs, but here is how it is done in various irqs.h file today:

- arch/arm/mach-exynos4/include/mach

/* PPI: Private Peripheral Interrupt */
#define IRQ_PPI(x)		S5P_IRQ(x+16)

/* SPI: Shared Peripheral Interrupt */
#define IRQ_SPI(x)		S5P_IRQ(x+32)

#define IRQ_EINT0		IRQ_SPI(16)
#define IRQ_EINT1		IRQ_SPI(17)
#define IRQ_EINT2		IRQ_SPI(18)
#define IRQ_EINT3		IRQ_SPI(19)


- arch/arm/mach-tegra/include/mach

/* Primary Interrupt Controller */
#define INT_PRI_BASE			(INT_GIC_BASE + 32)
#define INT_TMR1			(INT_PRI_BASE + 0)
#define INT_TMR2			(INT_PRI_BASE + 1)
#define INT_RTC				(INT_PRI_BASE + 2)
#define INT_I2S2			(INT_PRI_BASE + 3)


- arch/arm/mach-ux500/include/mach

/* Shared Peripheral Interrupt (SHPI) */
#define IRQ_SHPI_START			32

#define IRQ_MTU0		(IRQ_SHPI_START + 4)


- arch/arm/plat-omap/include/plat

#define OMAP44XX_IRQ_GIC_START			32

#define OMAP44XX_IRQ_PL310			(0 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_CTI0			(1 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_CTI1			(2 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_ELM			(4 + OMAP44XX_IRQ_GIC_START)


Every CortexA9 based SoC have to add the 32 offset to the SoC level interrupt number line. The ID numbering scheme is relevant only inside the GIC, but at SoC level only the IRQ lines that entered the MP core are relevant. That ID is a pure internal GIC encoding.

If you refer to the GIC-400 spec [2] (Please note that I do not know what that GIC is exactly...) p 25:
"SPIs are triggered by events generated on associated interrupt input lines. The GIC-400 can support up to 480 SPIs corresponding to the external IRQS[479:0] signal. The number of SPIs available depends on the implemented configuration of the GIC-400. The permitted values are 0-480, in steps of 32. SPIs start at ID32."

In that case the external IRQS numbering scheme is clear: [479:0], which is exactly what will be seen outside of the MP core.

Having two interrupt controllers, one for SGIs + PPIs starting at 0 (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to me a much better approach. Moreover, it will avoid exposing a cpumask for SPIs.

Regards,
Benoit


[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/I1006347.html

[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/18/2011 11:23 PM, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:

[...]

>>>>> I have another concern on a similar topic.
>>>>>
>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>>> 32. Only the internal PPI are between 0 and 31.
>>>>>
>>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>>
>>>> Those defines will not be used in the DT case. So the question is
>>>> whether to add 32 or not in the DT. Since we have just a single node and
>>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>>> agreement.
>>>
>>> This is a agreement inside the MPUSS, but not outside.
>>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>>> with that today.
>>>
>>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>>> dedicated irq domain for the SPI.
>>>>> The real HW physical number start at 0, and thus this is that value that
>>>>> should be in the irq binding of the device.
>>>>>
>>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>>
>>>>
>>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>>> controller, It will have 32 reserved interrupts and the register layout
>>>> is exactly the same as a cpu's GIC.
>>>
>>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>>> to tweak the HW number provided by the HW spec in order to add that offset.
>>> If you look at SoC level, the MPUSS is just an IP that can be
>>> potentially replaced by other one that will not have a GIC. In that case
>>> you will not change the IRQ mapping at SoC level.
>>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>>> all the interrupts will have to be shifted by 32 just because the MPU
>>> subsystem is different.
>>>
>>
>> Is that a realistic case? That would be a new chip and new device tree.
>> You could argue that the whole peripheral subsystem DT could be reused
>> and the numbering needs to be the same. However, there's one thing that
>> would prevent that. The number of interrupt cells is defined by the
>> controller binding. So you have to change the peripheral nodes anyway.
>>
>> It's good that OMAP is trying to standardize the peripheral layout, but
>> in my experience that's not something you can rely on.
>>
>> At some point the interrupt numbering is going to differ from the h/w
>> documentation. If it's not in the DT, then it will be in linux. Right
>> now its just offset of 32, but if irqdescs get assigned on demand as PPC
>> is doing, then there will be no relationship to the documentation.
>>
>>> Since that offset is dependent of the GIC internals and is not exposed
>>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>>> spec is exposing exactly that.
>>>
>>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>>> with a simple linear translation. Ultimately, domains will do dynamic
>>>> irqdesc allocation and the translation within the gic will be completely
>>>> dynamic.
>>>
>>> I think the only reason to do that is to separate internal MPU
>>> interrupts with the external ones that should not have a clue about the
>>> GIC.
>>
>> I see 2 options (besides leaving it as is):
>>
>> - Revert back to my previous binding where PPIs are a sub-node and a
>> different interrupt parent.
>>
>> - Use the current binding, but allow SPIs to start at 0. We can still
>> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
>> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
>> not be able to with this scheme.
>>
>> Either way you will still have the above issue with the cell size changing.
>>
> 
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?

Both SGI and PPI are internal to the CortexA9 MP core, and referring to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID# mapping is already documented:
- Private timer, PPI(2) Each Cortex-A9 processor has its own private timers that can generate interrupts, using ID29.
- Watchdog timers, PPI(3) Each Cortex-A9 processor has its own watchdog timers that can generate interrupts, using ID30.

So in that case, it can makes sense to use the ID. But it is interesting to note that the PPI is identified with a 0 based index number.

> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. 

Probably because it is the generic GIC spec that focus on internals stuff only, it not an integration spec that will show how the SPIs are connected to the outside world. But it is clear that the SPIs are identified as 0-XXX lines outside the Cortex MP core.

In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are triggered by events generated on associated interrupt input lines. The Interrupt Controller can support up to 224 interrupt input lines. The interrupt input lines can be configured to be edge sensitive (posedge) or level sensitive (high level).
SPIs start at ID32.

> All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type. The fact
> that the Cortex-A9 implementation has interrupt lines numbered equal to
> the GIC SPI interrupts is an implementation detail of the A9. 

> Other cores could have different arrangement including bringing out PPI
> interrupts or reserving some SPIs.

Absolutely, that's why we should not use that internal GIC convention to capture external IRQ mapping. It you separate the PPI and the SPI controller, you can allow any kind of internal mapping.

> As there are many users of the GIC, it makes more sense to align with
> the GIC documentation rather than the documentation of 1 SOC. BTW, I
> have the exact same issue in our documentation.

It is not about one SoC, this is probably done like that for every other SoCs. I do not have the TRM for the other SoCs, but here is how it is done in various irqs.h file today:

- arch/arm/mach-exynos4/include/mach

/* PPI: Private Peripheral Interrupt */
#define IRQ_PPI(x)		S5P_IRQ(x+16)

/* SPI: Shared Peripheral Interrupt */
#define IRQ_SPI(x)		S5P_IRQ(x+32)

#define IRQ_EINT0		IRQ_SPI(16)
#define IRQ_EINT1		IRQ_SPI(17)
#define IRQ_EINT2		IRQ_SPI(18)
#define IRQ_EINT3		IRQ_SPI(19)


- arch/arm/mach-tegra/include/mach

/* Primary Interrupt Controller */
#define INT_PRI_BASE			(INT_GIC_BASE + 32)
#define INT_TMR1			(INT_PRI_BASE + 0)
#define INT_TMR2			(INT_PRI_BASE + 1)
#define INT_RTC				(INT_PRI_BASE + 2)
#define INT_I2S2			(INT_PRI_BASE + 3)


- arch/arm/mach-ux500/include/mach

/* Shared Peripheral Interrupt (SHPI) */
#define IRQ_SHPI_START			32

#define IRQ_MTU0		(IRQ_SHPI_START + 4)


- arch/arm/plat-omap/include/plat

#define OMAP44XX_IRQ_GIC_START			32

#define OMAP44XX_IRQ_PL310			(0 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_CTI0			(1 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_CTI1			(2 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_ELM			(4 + OMAP44XX_IRQ_GIC_START)


Every CortexA9 based SoC have to add the 32 offset to the SoC level interrupt number line. The ID numbering scheme is relevant only inside the GIC, but at SoC level only the IRQ lines that entered the MP core are relevant. That ID is a pure internal GIC encoding.

If you refer to the GIC-400 spec [2] (Please note that I do not know what that GIC is exactly...) p 25:
"SPIs are triggered by events generated on associated interrupt input lines. The GIC-400 can support up to 480 SPIs corresponding to the external IRQS[479:0] signal. The number of SPIs available depends on the implemented configuration of the GIC-400. The permitted values are 0-480, in steps of 32. SPIs start at ID32."

In that case the external IRQS numbering scheme is clear: [479:0], which is exactly what will be seen outside of the MP core.

Having two interrupt controllers, one for SGIs + PPIs starting at 0 (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to me a much better approach. Moreover, it will avoid exposing a cpumask for SPIs.

Regards,
Benoit


[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/I1006347.html

[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/18/2011 11:23 PM, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:

[...]

>>>>> I have another concern on a similar topic.
>>>>>
>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have an offset of
>>>>> 32. Only the internal PPI are between 0 and 31.
>>>>>
>>>>> For the moment we add 32 to every SoC interrupts in the irq.h define,
>>>>
>>>> Those defines will not be used in the DT case. So the question is
>>>> whether to add 32 or not in the DT. Since we have just a single node and
>>>> a linear mapping of PPIs and SPIs, the only choice is to have SPIs start
>>>> at 32. And from the h/w definition, SPIs always start at 32, so it's in
>>>> agreement.
>>>
>>> This is a agreement inside the MPUSS, but not outside.
>>> Both Tegra and OMAP4 must add an offset to the HW irq number to deal
>>> with that today.
>>>
>>>>> but I'm assuming that this offset calculation should be done thanks to a
>>>>> dedicated irq domain for the SPI.
>>>>> The real HW physical number start at 0, and thus this is that value that
>>>>> should be in the irq binding of the device.
>>>>>
>>>>> So ideally we should have a irq domain for the PPI starting at 0 and
>>>>> another one for the SPI starting at 32. Or 32 and 64 for the exynos4
>>>>> case, but it looks like the PPI/SPI offset is always 32.
>>>>>
>>>>
>>>> That offset of SPIs is always there. If you have a GIC as a secondary
>>>> controller, It will have 32 reserved interrupts and the register layout
>>>> is exactly the same as a cpu's GIC.
>>>
>>> Yep, but that's the GIC view and not the SoC one. My concern is to have
>>> to tweak the HW number provided by the HW spec in order to add that offset.
>>> If you look at SoC level, the MPUSS is just an IP that can be
>>> potentially replaced by other one that will not have a GIC. In that case
>>> you will not change the IRQ mapping at SoC level.
>>> For example if you replace the Dual-cortexA9 by a single CortexA8, then
>>> all the interrupts will have to be shifted by 32 just because the MPU
>>> subsystem is different.
>>>
>>
>> Is that a realistic case? That would be a new chip and new device tree.
>> You could argue that the whole peripheral subsystem DT could be reused
>> and the numbering needs to be the same. However, there's one thing that
>> would prevent that. The number of interrupt cells is defined by the
>> controller binding. So you have to change the peripheral nodes anyway.
>>
>> It's good that OMAP is trying to standardize the peripheral layout, but
>> in my experience that's not something you can rely on.
>>
>> At some point the interrupt numbering is going to differ from the h/w
>> documentation. If it's not in the DT, then it will be in linux. Right
>> now its just offset of 32, but if irqdescs get assigned on demand as PPC
>> is doing, then there will be no relationship to the documentation.
>>
>>> Since that offset is dependent of the GIC internals and is not exposed
>>> outside the MPUSS, it should not be visible by the SoC IPs. And the HW
>>> spec is exposing exactly that.
>>>
>>>> Since the idea of splitting PPIs for each core out to a flattened linux
>>>> irq map has been abandoned, I see no reason to have more than 1 domain
>>>> with a simple linear translation. Ultimately, domains will do dynamic
>>>> irqdesc allocation and the translation within the gic will be completely
>>>> dynamic.
>>>
>>> I think the only reason to do that is to separate internal MPU
>>> interrupts with the external ones that should not have a clue about the
>>> GIC.
>>
>> I see 2 options (besides leaving it as is):
>>
>> - Revert back to my previous binding where PPIs are a sub-node and a
>> different interrupt parent.
>>
>> - Use the current binding, but allow SPIs to start at 0. We can still
>> distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
>> SPI. If there was ever a reason to have a cpu mask for an SPI, you would
>> not be able to with this scheme.
>>
>> Either way you will still have the above issue with the cell size changing.
>>
> 
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?

Both SGI and PPI are internal to the CortexA9 MP core, and referring to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID# mapping is already documented:
- Private timer, PPI(2) Each Cortex-A9 processor has its own private timers that can generate interrupts, using ID29.
- Watchdog timers, PPI(3) Each Cortex-A9 processor has its own watchdog timers that can generate interrupts, using ID30.

So in that case, it can makes sense to use the ID. But it is interesting to note that the PPI is identified with a 0 based index number.

> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. 

Probably because it is the generic GIC spec that focus on internals stuff only, it not an integration spec that will show how the SPIs are connected to the outside world. But it is clear that the SPIs are identified as 0-XXX lines outside the Cortex MP core.

In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are triggered by events generated on associated interrupt input lines. The Interrupt Controller can support up to 224 interrupt input lines. The interrupt input lines can be configured to be edge sensitive (posedge) or level sensitive (high level).
SPIs start at ID32.

> All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type. The fact
> that the Cortex-A9 implementation has interrupt lines numbered equal to
> the GIC SPI interrupts is an implementation detail of the A9. 

> Other cores could have different arrangement including bringing out PPI
> interrupts or reserving some SPIs.

Absolutely, that's why we should not use that internal GIC convention to capture external IRQ mapping. It you separate the PPI and the SPI controller, you can allow any kind of internal mapping.

> As there are many users of the GIC, it makes more sense to align with
> the GIC documentation rather than the documentation of 1 SOC. BTW, I
> have the exact same issue in our documentation.

It is not about one SoC, this is probably done like that for every other SoCs. I do not have the TRM for the other SoCs, but here is how it is done in various irqs.h file today:

- arch/arm/mach-exynos4/include/mach

/* PPI: Private Peripheral Interrupt */
#define IRQ_PPI(x)		S5P_IRQ(x+16)

/* SPI: Shared Peripheral Interrupt */
#define IRQ_SPI(x)		S5P_IRQ(x+32)

#define IRQ_EINT0		IRQ_SPI(16)
#define IRQ_EINT1		IRQ_SPI(17)
#define IRQ_EINT2		IRQ_SPI(18)
#define IRQ_EINT3		IRQ_SPI(19)


- arch/arm/mach-tegra/include/mach

/* Primary Interrupt Controller */
#define INT_PRI_BASE			(INT_GIC_BASE + 32)
#define INT_TMR1			(INT_PRI_BASE + 0)
#define INT_TMR2			(INT_PRI_BASE + 1)
#define INT_RTC				(INT_PRI_BASE + 2)
#define INT_I2S2			(INT_PRI_BASE + 3)


- arch/arm/mach-ux500/include/mach

/* Shared Peripheral Interrupt (SHPI) */
#define IRQ_SHPI_START			32

#define IRQ_MTU0		(IRQ_SHPI_START + 4)


- arch/arm/plat-omap/include/plat

#define OMAP44XX_IRQ_GIC_START			32

#define OMAP44XX_IRQ_PL310			(0 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_CTI0			(1 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_CTI1			(2 + OMAP44XX_IRQ_GIC_START)
#define OMAP44XX_IRQ_ELM			(4 + OMAP44XX_IRQ_GIC_START)


Every CortexA9 based SoC have to add the 32 offset to the SoC level interrupt number line. The ID numbering scheme is relevant only inside the GIC, but at SoC level only the IRQ lines that entered the MP core are relevant. That ID is a pure internal GIC encoding.

If you refer to the GIC-400 spec [2] (Please note that I do not know what that GIC is exactly...) p 25:
"SPIs are triggered by events generated on associated interrupt input lines. The GIC-400 can support up to 480 SPIs corresponding to the external IRQS[479:0] signal. The number of SPIs available depends on the implemented configuration of the GIC-400. The permitted values are 0-480, in steps of 32. SPIs start at ID32."

In that case the external IRQS numbering scheme is clear: [479:0], which is exactly what will be seen outside of the MP core.

Having two interrupt controllers, one for SGIs + PPIs starting at 0 (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to me a much better approach. Moreover, it will avoid exposing a cpumask for SPIs.

Regards,
Benoit


[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/I1006347.html

[2] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Grant,

On 18 September 2011 11:40, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 15 September 2011 18:24, Rob Herring <robherring2@gmail.com> wrote:
>> > On 09/15/2011 02:55 AM, Thomas Abraham wrote:
>> >>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> >>> +{
>> >>> +       void __iomem *cpu_base;
>> >>> +       void __iomem *dist_base;
>> >>> +       int irq;
>> >>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> >>> +
>> >>> +       if (WARN_ON(!node))
>> >>> +               return;
>> >>> +
>> >>> +       dist_base = of_iomap(node, 0);
>> >>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> >>> +
>> >>> +       cpu_base = of_iomap(node, 1);
>> >>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> >>> +
>> >>> +       domain->nr_irq = gic_irq_count(dist_base);
>> >>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>> >>
>> >> For exynos4, all the interrupts originating from GIC are statically
>> >> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> >> start from 64). In the above code, since irq_base would be 0 for
>> >> exynos4, the interrupt mapping is not working correctly. In your
>> >> previous version of the patch, you have given a option to the platform
>> >> code to choose the offset. Could that option be added to this series
>> >> also. Or a provision to use platform specific translate function
>> >> instead of the irq_domain_simple translator.
>> >>
>> >
>> > So I guess you have the A9 external nIRQ hooked up to another
>> > controller? Why can't the 0-31 interrupts get mapped to after the gic
>> > interrupts? Ultimately we want h/w irq numbers completely decoupled from
>> > linux irq numbers. So you will want to put that controller in devicetree
>> > and have an DT init function for it as well.
>>
>> There are chained interrupt handlers mapped in between linux irq
>> number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
>> = 32). The interrupt chaining for the interrupts mapped between 0 to
>> 31 seems unnecessary though. I will try removing them and check.
>
> Please note; when using the DT, the linux virq number should be
> dynamically assigned and therefore will not matter.  Historically
> Exynos may have started from irq 32, but it doesn't really have any
> relevance when all IRQ references are via DT irq specifiers.

Ok. But the exynos4 modules that have dt support depend on other
modules that are yet to get dt support. Those modules still use static
linux interrupt numbers and so until all the modules get dt support,
interrupt number specified in dt would have to follow the static
numbering that the rest of the system uses.

So to use Rob's patches for exynos4 dt, the interrupts mapped in the
range 1 to 31 will have to be reworked or moved to some other irq
numbers.

>
> Plus, for dynamically allocated irq_descs, I really want to make sure
> that irq 0 never gets assigned.  We're not supposed to be using it,
> and that becomes an easy rule to enforce when interrupt numbers are no
> longer assigned with #defines.
>
> g.
>

Thanks,
Thomas.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Grant,

On 18 September 2011 11:40, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 15 September 2011 18:24, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > On 09/15/2011 02:55 AM, Thomas Abraham wrote:
>> >>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> >>> +{
>> >>> +       void __iomem *cpu_base;
>> >>> +       void __iomem *dist_base;
>> >>> +       int irq;
>> >>> +       struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> >>> +
>> >>> +       if (WARN_ON(!node))
>> >>> +               return;
>> >>> +
>> >>> +       dist_base = of_iomap(node, 0);
>> >>> +       WARN(!dist_base, "unable to map gic dist registers\n");
>> >>> +
>> >>> +       cpu_base = of_iomap(node, 1);
>> >>> +       WARN(!cpu_base, "unable to map gic cpu registers\n");
>> >>> +
>> >>> +       domain->nr_irq = gic_irq_count(dist_base);
>> >>> +       domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>> >>
>> >> For exynos4, all the interrupts originating from GIC are statically
>> >> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> >> start from 64). In the above code, since irq_base would be 0 for
>> >> exynos4, the interrupt mapping is not working correctly. In your
>> >> previous version of the patch, you have given a option to the platform
>> >> code to choose the offset. Could that option be added to this series
>> >> also. Or a provision to use platform specific translate function
>> >> instead of the irq_domain_simple translator.
>> >>
>> >
>> > So I guess you have the A9 external nIRQ hooked up to another
>> > controller? Why can't the 0-31 interrupts get mapped to after the gic
>> > interrupts? Ultimately we want h/w irq numbers completely decoupled from
>> > linux irq numbers. So you will want to put that controller in devicetree
>> > and have an DT init function for it as well.
>>
>> There are chained interrupt handlers mapped in between linux irq
>> number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
>> = 32). The interrupt chaining for the interrupts mapped between 0 to
>> 31 seems unnecessary though. I will try removing them and check.
>
> Please note; when using the DT, the linux virq number should be
> dynamically assigned and therefore will not matter.  Historically
> Exynos may have started from irq 32, but it doesn't really have any
> relevance when all IRQ references are via DT irq specifiers.

Ok. But the exynos4 modules that have dt support depend on other
modules that are yet to get dt support. Those modules still use static
linux interrupt numbers and so until all the modules get dt support,
interrupt number specified in dt would have to follow the static
numbering that the rest of the system uses.

So to use Rob's patches for exynos4 dt, the interrupts mapped in the
range 1 to 31 will have to be reworked or moved to some other irq
numbers.

>
> Plus, for dynamically allocated irq_descs, I really want to make sure
> that irq 0 never gets assigned.  We're not supposed to be using it,
> and that becomes an easy rule to enforce when interrupt numbers are no
> longer assigned with #defines.
>
> g.
>

Thanks,
Thomas.

[PATCH 5/5] ARM: gic: add OF based initialization

[Thomas Abraham]

Hi Grant,

On 18 September 2011 11:40, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
>> Hi Rob,
>>
>> On 15 September 2011 18:24, Rob Herring <robherring2@gmail.com> wrote:
>> > On 09/15/2011 02:55 AM, Thomas Abraham wrote:
>> >>> +void __init gic_of_init(struct device_node *node, struct device_node *parent)
>> >>> +{
>> >>> + ? ? ? void __iomem *cpu_base;
>> >>> + ? ? ? void __iomem *dist_base;
>> >>> + ? ? ? int irq;
>> >>> + ? ? ? struct irq_domain *domain = &gic_data[gic_cnt].domain;
>> >>> +
>> >>> + ? ? ? if (WARN_ON(!node))
>> >>> + ? ? ? ? ? ? ? return;
>> >>> +
>> >>> + ? ? ? dist_base = of_iomap(node, 0);
>> >>> + ? ? ? WARN(!dist_base, "unable to map gic dist registers\n");
>> >>> +
>> >>> + ? ? ? cpu_base = of_iomap(node, 1);
>> >>> + ? ? ? WARN(!cpu_base, "unable to map gic cpu registers\n");
>> >>> +
>> >>> + ? ? ? domain->nr_irq = gic_irq_count(dist_base);
>> >>> + ? ? ? domain->irq_base = irq_alloc_descs(-1, 0, domain->nr_irq, numa_node_id());
>> >>
>> >> For exynos4, all the interrupts originating from GIC are statically
>> >> mapped to start from 32 in the linux virq space (GIC SPI interrupts
>> >> start from 64). In the above code, since irq_base would be 0 for
>> >> exynos4, the interrupt mapping is not working correctly. In your
>> >> previous version of the patch, you have given a option to the platform
>> >> code to choose the offset. Could that option be added to this series
>> >> also. Or a provision to use platform specific translate function
>> >> instead of the irq_domain_simple translator.
>> >>
>> >
>> > So I guess you have the A9 external nIRQ hooked up to another
>> > controller? Why can't the 0-31 interrupts get mapped to after the gic
>> > interrupts? Ultimately we want h/w irq numbers completely decoupled from
>> > linux irq numbers. So you will want to put that controller in devicetree
>> > and have an DT init function for it as well.
>>
>> There are chained interrupt handlers mapped in between linux irq
>> number 0 to 31. So the offset for GIC interrupts was set to 32 (SGI[0]
>> = 32). The interrupt chaining for the interrupts mapped between 0 to
>> 31 seems unnecessary though. I will try removing them and check.
>
> Please note; when using the DT, the linux virq number should be
> dynamically assigned and therefore will not matter. ?Historically
> Exynos may have started from irq 32, but it doesn't really have any
> relevance when all IRQ references are via DT irq specifiers.

Ok. But the exynos4 modules that have dt support depend on other
modules that are yet to get dt support. Those modules still use static
linux interrupt numbers and so until all the modules get dt support,
interrupt number specified in dt would have to follow the static
numbering that the rest of the system uses.

So to use Rob's patches for exynos4 dt, the interrupts mapped in the
range 1 to 31 will have to be reworked or moved to some other irq
numbers.

>
> Plus, for dynamically allocated irq_descs, I really want to make sure
> that irq 0 never gets assigned. ?We're not supposed to be using it,
> and that becomes an easy rule to enforce when interrupt numbers are no
> longer assigned with #defines.
>
> g.
>

Thanks,
Thomas.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 2:07 PM, Dave Martin wrote:
> On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely<grant.likely@secretlab.ca>  wrote:
>> On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
>>> For now, we express the mapping by putting an interrupt-map in the
>>> core-tile DT, but this feels inelegant as well as wasteful -- expressing
>>> "+ 32" using a table which is about 1K in size and duplicates that
>>> information 43 times.
>>>
>>> Using a dedicated irq domain or a fake interrupt controller node to
>>> encapsulate the motherboard interrupts feels like a cleaner approach,
>>> but for now I'm not clear on the best way to do it.
>>
>> An irq nexus node would indeed be something to investigate for your
>> particular case.  Look for examples of interrupt-map.  It is most
>> often used for handling IRQ swizzling on PCI busses.
>
> That's what I currently have -- this is logically correct, and it
> works; it just feels like a sledgehammer for cracking this particular
> nut, because we don't really have 43 independent interrupt mappings
> and types.  We have one offset and one type which is applied to all
> the interrupts, and this situation is expected to be the same for all
> variations of this board, except that offset may change.  I suspect
> this situation applies to many platforms -- the number of interrupts
> may in general be much larger than the number of independent mappings.
>
> Another way of looking at the problem is that it's difficult to come
> up with a one-size-fits-all description of interrupt mappings which is
> also efficient.  Requiring a single set of mapping semantics requires
> the mappings to be both rather overspecified for most cases, and
> flattened into a large, structureless table which may become pretty
> large and unwieldy.  If there were 100+ interrupts instead of 43, we'd
> really have to be generating the device tree using a script in order
> for it to be maintainable (which is not necessarily a problem, but can
> be a warning sign)

Yep, this is exactly the issue I was facing when I tried to map the 128 
interrupts lines of an OMAP4 to the GIC. Adding 128 entries to an 
interrupt map just to handle a simple linear translation with a constant 
value of 32 is clearly overkill.

> An alternative approach is to introduce a special interrupt controller
> node which serves as the interrupt-parent for the child domain and
> maps the interrupts with flexible semantics defined by the node's
> bindings; or different kinds of interrupt-map/interrupt-map-mask
> properties could be defined.  Bindings could be added as needed to
> support different cases -- though really we should only expect to have
> a small number at most.  When the interrupt mapping is significantly
> complex, using interrupt-map will probably be the best approach
> anyway.

Maybe we can just extend or add a new type of interrupt nexus to handle 
simple translation. The actual one was done for complex PCI mapping but 
with a small number of lines to handle. In our case, the mapping is 
simple, but the number of lines is huge.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 2:07 PM, Dave Martin wrote:
> On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>  wrote:
>> On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
>>> For now, we express the mapping by putting an interrupt-map in the
>>> core-tile DT, but this feels inelegant as well as wasteful -- expressing
>>> "+ 32" using a table which is about 1K in size and duplicates that
>>> information 43 times.
>>>
>>> Using a dedicated irq domain or a fake interrupt controller node to
>>> encapsulate the motherboard interrupts feels like a cleaner approach,
>>> but for now I'm not clear on the best way to do it.
>>
>> An irq nexus node would indeed be something to investigate for your
>> particular case.  Look for examples of interrupt-map.  It is most
>> often used for handling IRQ swizzling on PCI busses.
>
> That's what I currently have -- this is logically correct, and it
> works; it just feels like a sledgehammer for cracking this particular
> nut, because we don't really have 43 independent interrupt mappings
> and types.  We have one offset and one type which is applied to all
> the interrupts, and this situation is expected to be the same for all
> variations of this board, except that offset may change.  I suspect
> this situation applies to many platforms -- the number of interrupts
> may in general be much larger than the number of independent mappings.
>
> Another way of looking at the problem is that it's difficult to come
> up with a one-size-fits-all description of interrupt mappings which is
> also efficient.  Requiring a single set of mapping semantics requires
> the mappings to be both rather overspecified for most cases, and
> flattened into a large, structureless table which may become pretty
> large and unwieldy.  If there were 100+ interrupts instead of 43, we'd
> really have to be generating the device tree using a script in order
> for it to be maintainable (which is not necessarily a problem, but can
> be a warning sign)

Yep, this is exactly the issue I was facing when I tried to map the 128 
interrupts lines of an OMAP4 to the GIC. Adding 128 entries to an 
interrupt map just to handle a simple linear translation with a constant 
value of 32 is clearly overkill.

> An alternative approach is to introduce a special interrupt controller
> node which serves as the interrupt-parent for the child domain and
> maps the interrupts with flexible semantics defined by the node's
> bindings; or different kinds of interrupt-map/interrupt-map-mask
> properties could be defined.  Bindings could be added as needed to
> support different cases -- though really we should only expect to have
> a small number at most.  When the interrupt mapping is significantly
> complex, using interrupt-map will probably be the best approach
> anyway.

Maybe we can just extend or add a new type of interrupt nexus to handle 
simple translation. The actual one was done for complex PCI mapping but 
with a small number of lines to handle. In our case, the mapping is 
simple, but the number of lines is huge.

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 2:07 PM, Dave Martin wrote:
> On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely<grant.likely@secretlab.ca>  wrote:
>> On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
>>> For now, we express the mapping by putting an interrupt-map in the
>>> core-tile DT, but this feels inelegant as well as wasteful -- expressing
>>> "+ 32" using a table which is about 1K in size and duplicates that
>>> information 43 times.
>>>
>>> Using a dedicated irq domain or a fake interrupt controller node to
>>> encapsulate the motherboard interrupts feels like a cleaner approach,
>>> but for now I'm not clear on the best way to do it.
>>
>> An irq nexus node would indeed be something to investigate for your
>> particular case.  Look for examples of interrupt-map.  It is most
>> often used for handling IRQ swizzling on PCI busses.
>
> That's what I currently have -- this is logically correct, and it
> works; it just feels like a sledgehammer for cracking this particular
> nut, because we don't really have 43 independent interrupt mappings
> and types.  We have one offset and one type which is applied to all
> the interrupts, and this situation is expected to be the same for all
> variations of this board, except that offset may change.  I suspect
> this situation applies to many platforms -- the number of interrupts
> may in general be much larger than the number of independent mappings.
>
> Another way of looking at the problem is that it's difficult to come
> up with a one-size-fits-all description of interrupt mappings which is
> also efficient.  Requiring a single set of mapping semantics requires
> the mappings to be both rather overspecified for most cases, and
> flattened into a large, structureless table which may become pretty
> large and unwieldy.  If there were 100+ interrupts instead of 43, we'd
> really have to be generating the device tree using a script in order
> for it to be maintainable (which is not necessarily a problem, but can
> be a warning sign)

Yep, this is exactly the issue I was facing when I tried to map the 128 
interrupts lines of an OMAP4 to the GIC. Adding 128 entries to an 
interrupt map just to handle a simple linear translation with a constant 
value of 32 is clearly overkill.

> An alternative approach is to introduce a special interrupt controller
> node which serves as the interrupt-parent for the child domain and
> maps the interrupts with flexible semantics defined by the node's
> bindings; or different kinds of interrupt-map/interrupt-map-mask
> properties could be defined.  Bindings could be added as needed to
> support different cases -- though really we should only expect to have
> a small number at most.  When the interrupt mapping is significantly
> complex, using interrupt-map will probably be the best approach
> anyway.

Maybe we can just extend or add a new type of interrupt nexus to handle 
simple translation. The actual one was done for complex PCI mapping but 
with a small number of lines to handle. In our case, the mapping is 
simple, but the number of lines is huge.

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
> Since the cpumask is not relevant for the SPI, maybe having two  
> interrupt controllers will be more relevant. Or maybe 3, since there is  
> some SGIs as well.

I don't think anyone uses SGIs outside of the common SMP code.
Therefore they're handled entirely separately for the root GIC.

(If there's two GICs - some platforms do have two - then the SGIs on
the non-root GIC are unused.)

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
> Since the cpumask is not relevant for the SPI, maybe having two  
> interrupt controllers will be more relevant. Or maybe 3, since there is  
> some SGIs as well.

I don't think anyone uses SGIs outside of the common SMP code.
Therefore they're handled entirely separately for the root GIC.

(If there's two GICs - some platforms do have two - then the SGIs on
the non-root GIC are unused.)

[PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
> Since the cpumask is not relevant for the SPI, maybe having two  
> interrupt controllers will be more relevant. Or maybe 3, since there is  
> some SGIs as well.

I don't think anyone uses SGIs outside of the common SMP code.
Therefore they're handled entirely separately for the root GIC.

(If there's two GICs - some platforms do have two - then the SGIs on
the non-root GIC are unused.)

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
> On 9/18/2011 11:23 PM, Rob Herring wrote:
>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> 
> [...]
> 
>>>>>> I have another concern on a similar topic.
>>>>>> 
>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>> 31.
>>>>>> 
>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>> irq.h define,
>>>>> 
>>>>> Those defines will not be used in the DT case. So the
>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>> 
>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>> deal with that today.
>>>> 
>>>>>> but I'm assuming that this offset calculation should be
>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>> HW physical number start at 0, and thus this is that value
>>>>>> that should be in the irq binding of the device.
>>>>>> 
>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>> offset is always 32.
>>>>>> 
>>>>> 
>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>> the register layout is exactly the same as a cpu's GIC.
>>>> 
>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>> to have to tweak the HW number provided by the HW spec in order
>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>> an IP that can be potentially replaced by other one that will
>>>> not have a GIC. In that case you will not change the IRQ
>>>> mapping at SoC level. For example if you replace the
>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>> different.
>>>> 
>>> 
>>> Is that a realistic case? That would be a new chip and new device
>>> tree. You could argue that the whole peripheral subsystem DT
>>> could be reused and the numbering needs to be the same. However,
>>> there's one thing that would prevent that. The number of
>>> interrupt cells is defined by the controller binding. So you have
>>> to change the peripheral nodes anyway.
>>> 
>>> It's good that OMAP is trying to standardize the peripheral
>>> layout, but in my experience that's not something you can rely
>>> on.
>>> 
>>> At some point the interrupt numbering is going to differ from the
>>> h/w documentation. If it's not in the DT, then it will be in
>>> linux. Right now its just offset of 32, but if irqdescs get
>>> assigned on demand as PPC is doing, then there will be no
>>> relationship to the documentation.
>>> 
>>>> Since that offset is dependent of the GIC internals and is not
>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>> IPs. And the HW spec is exposing exactly that.
>>>> 
>>>>> Since the idea of splitting PPIs for each core out to a
>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>> to have more than 1 domain with a simple linear translation.
>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>> the translation within the gic will be completely dynamic.
>>>> 
>>>> I think the only reason to do that is to separate internal MPU 
>>>> interrupts with the external ones that should not have a clue
>>>> about the GIC.
>>> 
>>> I see 2 options (besides leaving it as is):
>>> 
>>> - Revert back to my previous binding where PPIs are a sub-node
>>> and a different interrupt parent.
>>> 
>>> - Use the current binding, but allow SPIs to start at 0. We can
>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>> an SPI, you would not be able to with this scheme.
>>> 
>>> Either way you will still have the above issue with the cell size
>>> changing.
>>> 
>> 
>> I was headed down the path of implementing the 2nd option above,
>> but had a dilemma. What would be the numbering base for PPIs in
>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>> stay at 16?
> 
> Both SGI and PPI are internal to the CortexA9 MP core, and referring
> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
> processor has its own private timers that can generate interrupts,
> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
> its own watchdog timers that can generate interrupts, using ID30.
> 
> So in that case, it can makes sense to use the ID. But it is
> interesting to note that the PPI is identified with a 0 based index
> number.
> 
It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
for the timer interrupt. The first would match 0 based SPI convention.
The last 2 would both match the documentation. We could never use 2 as
this will for sure be different and the GIC code will have no way to
know how to do the translation to ID. The only sane choice is using the
ID as you say.

But you can't have it both ways. It does not make sense to use the ID
for some interrupts and a different scheme for others.

>> Numbering PPIs at 0 will just cause confusion as will numbering 
>> differently from SPIs. There is absolutely no mention of SPI0 or
>> SPIx numbering in the GIC spec.
> 
> Probably because it is the generic GIC spec that focus on internals
> stuff only, it not an integration spec that will show how the SPIs
> are connected to the outside world. But it is clear that the SPIs are
> identified as 0-XXX lines outside the Cortex MP core.
> 

What if the A9 or some other implementation used some SPIs internally?
Then the external connection would be shifted differently. The interrupt
binding for a peripheral is defined by it's interrupt parent (the
interrupt controller). The number of cells and what the values mean are
defined by the interrupt controller binding. This is independent of any
SOC. The binding must be defined from the perspective of the interrupt
controller.

> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
> triggered by events generated on associated interrupt input lines.
> The Interrupt Controller can support up to 224 interrupt input lines.
> The interrupt input lines can be configured to be edge sensitive
> (posedge) or level sensitive (high level). SPIs start at ID32.
> 
>> All interrupt number references refer to the absolute interrupt ID,
>> not a relative number based on the type. The fact that the
>> Cortex-A9 implementation has interrupt lines numbered equal to the
>> GIC SPI interrupts is an implementation detail of the A9.
> 
>> Other cores could have different arrangement including bringing out
>> PPI interrupts or reserving some SPIs.
> 
> Absolutely, that's why we should not use that internal GIC convention
> to capture external IRQ mapping. It you separate the PPI and the SPI
> controller, you can allow any kind of internal mapping.
> 

The GIC convention is the only part that is consistent and not dependent
on the implementation.

>> As there are many users of the GIC, it makes more sense to align
>> with the GIC documentation rather than the documentation of 1 SOC.
>> BTW, I have the exact same issue in our documentation.
> 
> It is not about one SoC, this is probably done like that for every
> other SoCs. I do not have the TRM for the other SoCs, but here is how
> it is done in various irqs.h file today:
> 
> - arch/arm/mach-exynos4/include/mach
> 
> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
> S5P_IRQ(x+16)
> 
> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
> S5P_IRQ(x+32)
> 
> #define IRQ_EINT0		IRQ_SPI(16) #define IRQ_EINT1		IRQ_SPI(17) #define
> IRQ_EINT2		IRQ_SPI(18) #define IRQ_EINT3		IRQ_SPI(19)
> 
> 
> - arch/arm/mach-tegra/include/mach
> 
> /* Primary Interrupt Controller */ #define INT_PRI_BASE
> (INT_GIC_BASE + 32) #define INT_TMR1			(INT_PRI_BASE + 0) #define
> INT_TMR2			(INT_PRI_BASE + 1) #define INT_RTC				(INT_PRI_BASE + 2) 
> #define INT_I2S2			(INT_PRI_BASE + 3)
> 
> 
> - arch/arm/mach-ux500/include/mach
> 
> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START			32
> 
> #define IRQ_MTU0		(IRQ_SHPI_START + 4)
> 
> 
> - arch/arm/plat-omap/include/plat
> 
> #define OMAP44XX_IRQ_GIC_START			32
> 
> #define OMAP44XX_IRQ_PL310			(0 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_CTI0			(1 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_CTI1			(2 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_ELM			(4 + OMAP44XX_IRQ_GIC_START)
> 
> 
> Every CortexA9 based SoC have to add the 32 offset to the SoC level
> interrupt number line. The ID numbering scheme is relevant only
> inside the GIC, but at SoC level only the IRQ lines that entered the
> MP core are relevant. That ID is a pure internal GIC encoding.
> 
Exactly. For DT, the irq numbering is supposed to be local to the
interrupt controller. So from a GIC perspective, what numbering makes sense?

It's also relevant to the software running on the system.

> If you refer to the GIC-400 spec [2] (Please note that I do not know
> what that GIC is exactly...) p 25: "SPIs are triggered by events
> generated on associated interrupt input lines. The GIC-400 can
> support up to 480 SPIs corresponding to the external IRQS[479:0]
> signal. The number of SPIs available depends on the implemented
> configuration of the GIC-400. The permitted values are 0-480, in
> steps of 32. SPIs start at ID32."
> 
> In that case the external IRQS numbering scheme is clear: [479:0],
> which is exactly what will be seen outside of the MP core.
> 
> Having two interrupt controllers, one for SGIs + PPIs starting at 0
> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
> me a much better approach. Moreover, it will avoid exposing a cpumask
> for SPIs.
> 

Having implemented both ways already, I'm fine either way, but the
current consensus seems to be to use the cpumask.

Rob

> Regards, Benoit
> 
> 
> [1]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/I1006347.html
>
>  [2]
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf
>
> 
> 
> 

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
> On 9/18/2011 11:23 PM, Rob Herring wrote:
>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> 
> [...]
> 
>>>>>> I have another concern on a similar topic.
>>>>>> 
>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>> 31.
>>>>>> 
>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>> irq.h define,
>>>>> 
>>>>> Those defines will not be used in the DT case. So the
>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>> 
>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>> deal with that today.
>>>> 
>>>>>> but I'm assuming that this offset calculation should be
>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>> HW physical number start at 0, and thus this is that value
>>>>>> that should be in the irq binding of the device.
>>>>>> 
>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>> offset is always 32.
>>>>>> 
>>>>> 
>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>> the register layout is exactly the same as a cpu's GIC.
>>>> 
>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>> to have to tweak the HW number provided by the HW spec in order
>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>> an IP that can be potentially replaced by other one that will
>>>> not have a GIC. In that case you will not change the IRQ
>>>> mapping at SoC level. For example if you replace the
>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>> different.
>>>> 
>>> 
>>> Is that a realistic case? That would be a new chip and new device
>>> tree. You could argue that the whole peripheral subsystem DT
>>> could be reused and the numbering needs to be the same. However,
>>> there's one thing that would prevent that. The number of
>>> interrupt cells is defined by the controller binding. So you have
>>> to change the peripheral nodes anyway.
>>> 
>>> It's good that OMAP is trying to standardize the peripheral
>>> layout, but in my experience that's not something you can rely
>>> on.
>>> 
>>> At some point the interrupt numbering is going to differ from the
>>> h/w documentation. If it's not in the DT, then it will be in
>>> linux. Right now its just offset of 32, but if irqdescs get
>>> assigned on demand as PPC is doing, then there will be no
>>> relationship to the documentation.
>>> 
>>>> Since that offset is dependent of the GIC internals and is not
>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>> IPs. And the HW spec is exposing exactly that.
>>>> 
>>>>> Since the idea of splitting PPIs for each core out to a
>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>> to have more than 1 domain with a simple linear translation.
>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>> the translation within the gic will be completely dynamic.
>>>> 
>>>> I think the only reason to do that is to separate internal MPU 
>>>> interrupts with the external ones that should not have a clue
>>>> about the GIC.
>>> 
>>> I see 2 options (besides leaving it as is):
>>> 
>>> - Revert back to my previous binding where PPIs are a sub-node
>>> and a different interrupt parent.
>>> 
>>> - Use the current binding, but allow SPIs to start at 0. We can
>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>> an SPI, you would not be able to with this scheme.
>>> 
>>> Either way you will still have the above issue with the cell size
>>> changing.
>>> 
>> 
>> I was headed down the path of implementing the 2nd option above,
>> but had a dilemma. What would be the numbering base for PPIs in
>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>> stay at 16?
> 
> Both SGI and PPI are internal to the CortexA9 MP core, and referring
> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
> processor has its own private timers that can generate interrupts,
> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
> its own watchdog timers that can generate interrupts, using ID30.
> 
> So in that case, it can makes sense to use the ID. But it is
> interesting to note that the PPI is identified with a 0 based index
> number.
> 
It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
for the timer interrupt. The first would match 0 based SPI convention.
The last 2 would both match the documentation. We could never use 2 as
this will for sure be different and the GIC code will have no way to
know how to do the translation to ID. The only sane choice is using the
ID as you say.

But you can't have it both ways. It does not make sense to use the ID
for some interrupts and a different scheme for others.

>> Numbering PPIs at 0 will just cause confusion as will numbering 
>> differently from SPIs. There is absolutely no mention of SPI0 or
>> SPIx numbering in the GIC spec.
> 
> Probably because it is the generic GIC spec that focus on internals
> stuff only, it not an integration spec that will show how the SPIs
> are connected to the outside world. But it is clear that the SPIs are
> identified as 0-XXX lines outside the Cortex MP core.
> 

What if the A9 or some other implementation used some SPIs internally?
Then the external connection would be shifted differently. The interrupt
binding for a peripheral is defined by it's interrupt parent (the
interrupt controller). The number of cells and what the values mean are
defined by the interrupt controller binding. This is independent of any
SOC. The binding must be defined from the perspective of the interrupt
controller.

> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
> triggered by events generated on associated interrupt input lines.
> The Interrupt Controller can support up to 224 interrupt input lines.
> The interrupt input lines can be configured to be edge sensitive
> (posedge) or level sensitive (high level). SPIs start at ID32.
> 
>> All interrupt number references refer to the absolute interrupt ID,
>> not a relative number based on the type. The fact that the
>> Cortex-A9 implementation has interrupt lines numbered equal to the
>> GIC SPI interrupts is an implementation detail of the A9.
> 
>> Other cores could have different arrangement including bringing out
>> PPI interrupts or reserving some SPIs.
> 
> Absolutely, that's why we should not use that internal GIC convention
> to capture external IRQ mapping. It you separate the PPI and the SPI
> controller, you can allow any kind of internal mapping.
> 

The GIC convention is the only part that is consistent and not dependent
on the implementation.

>> As there are many users of the GIC, it makes more sense to align
>> with the GIC documentation rather than the documentation of 1 SOC.
>> BTW, I have the exact same issue in our documentation.
> 
> It is not about one SoC, this is probably done like that for every
> other SoCs. I do not have the TRM for the other SoCs, but here is how
> it is done in various irqs.h file today:
> 
> - arch/arm/mach-exynos4/include/mach
> 
> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
> S5P_IRQ(x+16)
> 
> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
> S5P_IRQ(x+32)
> 
> #define IRQ_EINT0		IRQ_SPI(16) #define IRQ_EINT1		IRQ_SPI(17) #define
> IRQ_EINT2		IRQ_SPI(18) #define IRQ_EINT3		IRQ_SPI(19)
> 
> 
> - arch/arm/mach-tegra/include/mach
> 
> /* Primary Interrupt Controller */ #define INT_PRI_BASE
> (INT_GIC_BASE + 32) #define INT_TMR1			(INT_PRI_BASE + 0) #define
> INT_TMR2			(INT_PRI_BASE + 1) #define INT_RTC				(INT_PRI_BASE + 2) 
> #define INT_I2S2			(INT_PRI_BASE + 3)
> 
> 
> - arch/arm/mach-ux500/include/mach
> 
> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START			32
> 
> #define IRQ_MTU0		(IRQ_SHPI_START + 4)
> 
> 
> - arch/arm/plat-omap/include/plat
> 
> #define OMAP44XX_IRQ_GIC_START			32
> 
> #define OMAP44XX_IRQ_PL310			(0 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_CTI0			(1 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_CTI1			(2 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_ELM			(4 + OMAP44XX_IRQ_GIC_START)
> 
> 
> Every CortexA9 based SoC have to add the 32 offset to the SoC level
> interrupt number line. The ID numbering scheme is relevant only
> inside the GIC, but at SoC level only the IRQ lines that entered the
> MP core are relevant. That ID is a pure internal GIC encoding.
> 
Exactly. For DT, the irq numbering is supposed to be local to the
interrupt controller. So from a GIC perspective, what numbering makes sense?

It's also relevant to the software running on the system.

> If you refer to the GIC-400 spec [2] (Please note that I do not know
> what that GIC is exactly...) p 25: "SPIs are triggered by events
> generated on associated interrupt input lines. The GIC-400 can
> support up to 480 SPIs corresponding to the external IRQS[479:0]
> signal. The number of SPIs available depends on the implemented
> configuration of the GIC-400. The permitted values are 0-480, in
> steps of 32. SPIs start at ID32."
> 
> In that case the external IRQS numbering scheme is clear: [479:0],
> which is exactly what will be seen outside of the MP core.
> 
> Having two interrupt controllers, one for SGIs + PPIs starting at 0
> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
> me a much better approach. Moreover, it will avoid exposing a cpumask
> for SPIs.
> 

Having implemented both ways already, I'm fine either way, but the
current consensus seems to be to use the cpumask.

Rob

> Regards, Benoit
> 
> 
> [1]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/I1006347.html
>
>  [2]
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf
>
> 
> 
> 

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
> On 9/18/2011 11:23 PM, Rob Herring wrote:
>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
> 
> [...]
> 
>>>>>> I have another concern on a similar topic.
>>>>>> 
>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>> 31.
>>>>>> 
>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>> irq.h define,
>>>>> 
>>>>> Those defines will not be used in the DT case. So the
>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>> 
>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>> deal with that today.
>>>> 
>>>>>> but I'm assuming that this offset calculation should be
>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>> HW physical number start at 0, and thus this is that value
>>>>>> that should be in the irq binding of the device.
>>>>>> 
>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>> offset is always 32.
>>>>>> 
>>>>> 
>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>> the register layout is exactly the same as a cpu's GIC.
>>>> 
>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>> to have to tweak the HW number provided by the HW spec in order
>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>> an IP that can be potentially replaced by other one that will
>>>> not have a GIC. In that case you will not change the IRQ
>>>> mapping at SoC level. For example if you replace the
>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>> different.
>>>> 
>>> 
>>> Is that a realistic case? That would be a new chip and new device
>>> tree. You could argue that the whole peripheral subsystem DT
>>> could be reused and the numbering needs to be the same. However,
>>> there's one thing that would prevent that. The number of
>>> interrupt cells is defined by the controller binding. So you have
>>> to change the peripheral nodes anyway.
>>> 
>>> It's good that OMAP is trying to standardize the peripheral
>>> layout, but in my experience that's not something you can rely
>>> on.
>>> 
>>> At some point the interrupt numbering is going to differ from the
>>> h/w documentation. If it's not in the DT, then it will be in
>>> linux. Right now its just offset of 32, but if irqdescs get
>>> assigned on demand as PPC is doing, then there will be no
>>> relationship to the documentation.
>>> 
>>>> Since that offset is dependent of the GIC internals and is not
>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>> IPs. And the HW spec is exposing exactly that.
>>>> 
>>>>> Since the idea of splitting PPIs for each core out to a
>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>> to have more than 1 domain with a simple linear translation.
>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>> the translation within the gic will be completely dynamic.
>>>> 
>>>> I think the only reason to do that is to separate internal MPU 
>>>> interrupts with the external ones that should not have a clue
>>>> about the GIC.
>>> 
>>> I see 2 options (besides leaving it as is):
>>> 
>>> - Revert back to my previous binding where PPIs are a sub-node
>>> and a different interrupt parent.
>>> 
>>> - Use the current binding, but allow SPIs to start at 0. We can
>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>> an SPI, you would not be able to with this scheme.
>>> 
>>> Either way you will still have the above issue with the cell size
>>> changing.
>>> 
>> 
>> I was headed down the path of implementing the 2nd option above,
>> but had a dilemma. What would be the numbering base for PPIs in
>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>> stay at 16?
> 
> Both SGI and PPI are internal to the CortexA9 MP core, and referring
> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
> processor has its own private timers that can generate interrupts,
> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
> its own watchdog timers that can generate interrupts, using ID30.
> 
> So in that case, it can makes sense to use the ID. But it is
> interesting to note that the PPI is identified with a 0 based index
> number.
> 
It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
for the timer interrupt. The first would match 0 based SPI convention.
The last 2 would both match the documentation. We could never use 2 as
this will for sure be different and the GIC code will have no way to
know how to do the translation to ID. The only sane choice is using the
ID as you say.

But you can't have it both ways. It does not make sense to use the ID
for some interrupts and a different scheme for others.

>> Numbering PPIs at 0 will just cause confusion as will numbering 
>> differently from SPIs. There is absolutely no mention of SPI0 or
>> SPIx numbering in the GIC spec.
> 
> Probably because it is the generic GIC spec that focus on internals
> stuff only, it not an integration spec that will show how the SPIs
> are connected to the outside world. But it is clear that the SPIs are
> identified as 0-XXX lines outside the Cortex MP core.
> 

What if the A9 or some other implementation used some SPIs internally?
Then the external connection would be shifted differently. The interrupt
binding for a peripheral is defined by it's interrupt parent (the
interrupt controller). The number of cells and what the values mean are
defined by the interrupt controller binding. This is independent of any
SOC. The binding must be defined from the perspective of the interrupt
controller.

> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
> triggered by events generated on associated interrupt input lines.
> The Interrupt Controller can support up to 224 interrupt input lines.
> The interrupt input lines can be configured to be edge sensitive
> (posedge) or level sensitive (high level). SPIs start at ID32.
> 
>> All interrupt number references refer to the absolute interrupt ID,
>> not a relative number based on the type. The fact that the
>> Cortex-A9 implementation has interrupt lines numbered equal to the
>> GIC SPI interrupts is an implementation detail of the A9.
> 
>> Other cores could have different arrangement including bringing out
>> PPI interrupts or reserving some SPIs.
> 
> Absolutely, that's why we should not use that internal GIC convention
> to capture external IRQ mapping. It you separate the PPI and the SPI
> controller, you can allow any kind of internal mapping.
> 

The GIC convention is the only part that is consistent and not dependent
on the implementation.

>> As there are many users of the GIC, it makes more sense to align
>> with the GIC documentation rather than the documentation of 1 SOC.
>> BTW, I have the exact same issue in our documentation.
> 
> It is not about one SoC, this is probably done like that for every
> other SoCs. I do not have the TRM for the other SoCs, but here is how
> it is done in various irqs.h file today:
> 
> - arch/arm/mach-exynos4/include/mach
> 
> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
> S5P_IRQ(x+16)
> 
> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
> S5P_IRQ(x+32)
> 
> #define IRQ_EINT0		IRQ_SPI(16) #define IRQ_EINT1		IRQ_SPI(17) #define
> IRQ_EINT2		IRQ_SPI(18) #define IRQ_EINT3		IRQ_SPI(19)
> 
> 
> - arch/arm/mach-tegra/include/mach
> 
> /* Primary Interrupt Controller */ #define INT_PRI_BASE
> (INT_GIC_BASE + 32) #define INT_TMR1			(INT_PRI_BASE + 0) #define
> INT_TMR2			(INT_PRI_BASE + 1) #define INT_RTC				(INT_PRI_BASE + 2) 
> #define INT_I2S2			(INT_PRI_BASE + 3)
> 
> 
> - arch/arm/mach-ux500/include/mach
> 
> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START			32
> 
> #define IRQ_MTU0		(IRQ_SHPI_START + 4)
> 
> 
> - arch/arm/plat-omap/include/plat
> 
> #define OMAP44XX_IRQ_GIC_START			32
> 
> #define OMAP44XX_IRQ_PL310			(0 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_CTI0			(1 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_CTI1			(2 + OMAP44XX_IRQ_GIC_START) #define
> OMAP44XX_IRQ_ELM			(4 + OMAP44XX_IRQ_GIC_START)
> 
> 
> Every CortexA9 based SoC have to add the 32 offset to the SoC level
> interrupt number line. The ID numbering scheme is relevant only
> inside the GIC, but at SoC level only the IRQ lines that entered the
> MP core are relevant. That ID is a pure internal GIC encoding.
> 
Exactly. For DT, the irq numbering is supposed to be local to the
interrupt controller. So from a GIC perspective, what numbering makes sense?

It's also relevant to the software running on the system.

> If you refer to the GIC-400 spec [2] (Please note that I do not know
> what that GIC is exactly...) p 25: "SPIs are triggered by events
> generated on associated interrupt input lines. The GIC-400 can
> support up to 480 SPIs corresponding to the external IRQS[479:0]
> signal. The number of SPIs available depends on the implemented
> configuration of the GIC-400. The permitted values are 0-480, in
> steps of 32. SPIs start at ID32."
> 
> In that case the external IRQS numbering scheme is clear: [479:0],
> which is exactly what will be seen outside of the MP core.
> 
> Having two interrupt controllers, one for SGIs + PPIs starting at 0
> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
> me a much better approach. Moreover, it will avoid exposing a cpumask
> for SPIs.
> 

Having implemented both ways already, I'm fine either way, but the
current consensus seems to be to use the cpumask.

Rob

> Regards, Benoit
> 
> 
> [1]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/I1006347.html
>
>  [2]
> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf
>
> 
> 
> 

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 3:48 PM, Rob Herring wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>>> I have another concern on a similar topic.
>>>>>>>
>>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>>> 31.
>>>>>>>
>>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>>> irq.h define,
>>>>>>
>>>>>> Those defines will not be used in the DT case. So the
>>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>>>
>>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>>> deal with that today.
>>>>>
>>>>>>> but I'm assuming that this offset calculation should be
>>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>>> HW physical number start at 0, and thus this is that value
>>>>>>> that should be in the irq binding of the device.
>>>>>>>
>>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>>> offset is always 32.
>>>>>>>
>>>>>>
>>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>>> the register layout is exactly the same as a cpu's GIC.
>>>>>
>>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>>> to have to tweak the HW number provided by the HW spec in order
>>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>>> an IP that can be potentially replaced by other one that will
>>>>> not have a GIC. In that case you will not change the IRQ
>>>>> mapping at SoC level. For example if you replace the
>>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>>> different.
>>>>>
>>>>
>>>> Is that a realistic case? That would be a new chip and new device
>>>> tree. You could argue that the whole peripheral subsystem DT
>>>> could be reused and the numbering needs to be the same. However,
>>>> there's one thing that would prevent that. The number of
>>>> interrupt cells is defined by the controller binding. So you have
>>>> to change the peripheral nodes anyway.
>>>>
>>>> It's good that OMAP is trying to standardize the peripheral
>>>> layout, but in my experience that's not something you can rely
>>>> on.
>>>>
>>>> At some point the interrupt numbering is going to differ from the
>>>> h/w documentation. If it's not in the DT, then it will be in
>>>> linux. Right now its just offset of 32, but if irqdescs get
>>>> assigned on demand as PPC is doing, then there will be no
>>>> relationship to the documentation.
>>>>
>>>>> Since that offset is dependent of the GIC internals and is not
>>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>>> IPs. And the HW spec is exposing exactly that.
>>>>>
>>>>>> Since the idea of splitting PPIs for each core out to a
>>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>>> to have more than 1 domain with a simple linear translation.
>>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>>> the translation within the gic will be completely dynamic.
>>>>>
>>>>> I think the only reason to do that is to separate internal MPU
>>>>> interrupts with the external ones that should not have a clue
>>>>> about the GIC.
>>>>
>>>> I see 2 options (besides leaving it as is):
>>>>
>>>> - Revert back to my previous binding where PPIs are a sub-node
>>>> and a different interrupt parent.
>>>>
>>>> - Use the current binding, but allow SPIs to start at 0. We can
>>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>>> an SPI, you would not be able to with this scheme.
>>>>
>>>> Either way you will still have the above issue with the cell size
>>>> changing.
>>>>
>>>
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# ->  ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.

I didn't even noticed that mess :-(
Maybe that PPI number is not that relevant in that case. It looks like 
there are using the last 4 lines (28-31).

> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.

In that case, this is indeed the case.

> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.

Maybe not, the idea is to use the scheme that is the most relevant for a 
particular subsystem. Inside the CortexA9 MP the documentation clearly 
gives the mapping based on ID#. But for SPIs, it is just written start 
as ID32.

>>> Numbering PPIs at 0 will just cause confusion as will numbering
>>> differently from SPIs. There is absolutely no mention of SPI0 or
>>> SPIx numbering in the GIC spec.
>>
>> Probably because it is the generic GIC spec that focus on internals
>> stuff only, it not an integration spec that will show how the SPIs
>> are connected to the outside world. But it is clear that the SPIs are
>> identified as 0-XXX lines outside the Cortex MP core.
>>
>
> What if the A9 or some other implementation used some SPIs internally?
> Then the external connection would be shifted differently.

Potentially yes.

> The interrupt
> binding for a peripheral is defined by it's interrupt parent (the
> interrupt controller). The number of cells and what the values mean are
> defined by the interrupt controller binding. This is independent of any
> SOC. The binding must be defined from the perspective of the interrupt
> controller.

In fact, it is dependent on both the interrupt controller binding, and 
the way the interrupt controller is connected to the SoC. It should be 
defined as well based on the interface exposed to the outside of the 
subsystem.

>> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
>> triggered by events generated on associated interrupt input lines.
>> The Interrupt Controller can support up to 224 interrupt input lines.
>> The interrupt input lines can be configured to be edge sensitive
>> (posedge) or level sensitive (high level). SPIs start at ID32.
>>
>>> All interrupt number references refer to the absolute interrupt ID,
>>> not a relative number based on the type. The fact that the
>>> Cortex-A9 implementation has interrupt lines numbered equal to the
>>> GIC SPI interrupts is an implementation detail of the A9.
>>
>>> Other cores could have different arrangement including bringing out
>>> PPI interrupts or reserving some SPIs.
>>
>> Absolutely, that's why we should not use that internal GIC convention
>> to capture external IRQ mapping. It you separate the PPI and the SPI
>> controller, you can allow any kind of internal mapping.
>>
>
> The GIC convention is the only part that is consistent and not dependent
> on the implementation.

Again, for the point of view of the GIC, but not necessarily for the SoC 
point of view.

>>> As there are many users of the GIC, it makes more sense to align
>>> with the GIC documentation rather than the documentation of 1 SOC.
>>> BTW, I have the exact same issue in our documentation.
>>
>> It is not about one SoC, this is probably done like that for every
>> other SoCs. I do not have the TRM for the other SoCs, but here is how
>> it is done in various irqs.h file today:
>>
>> - arch/arm/mach-exynos4/include/mach
>>
>> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
>> S5P_IRQ(x+16)
>>
>> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
>> S5P_IRQ(x+32)
>>
>> #define IRQ_EINT0             IRQ_SPI(16) #define IRQ_EINT1           IRQ_SPI(17) #define
>> IRQ_EINT2             IRQ_SPI(18) #define IRQ_EINT3           IRQ_SPI(19)
>>
>>
>> - arch/arm/mach-tegra/include/mach
>>
>> /* Primary Interrupt Controller */ #define INT_PRI_BASE
>> (INT_GIC_BASE + 32) #define INT_TMR1                  (INT_PRI_BASE + 0) #define
>> INT_TMR2                      (INT_PRI_BASE + 1) #define INT_RTC                              (INT_PRI_BASE + 2)
>> #define INT_I2S2                      (INT_PRI_BASE + 3)
>>
>>
>> - arch/arm/mach-ux500/include/mach
>>
>> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START                       32
>>
>> #define IRQ_MTU0              (IRQ_SHPI_START + 4)
>>
>>
>> - arch/arm/plat-omap/include/plat
>>
>> #define OMAP44XX_IRQ_GIC_START                        32
>>
>> #define OMAP44XX_IRQ_PL310                    (0 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI0                     (1 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI1                     (2 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_ELM                      (4 + OMAP44XX_IRQ_GIC_START)
>>
>>
>> Every CortexA9 based SoC have to add the 32 offset to the SoC level
>> interrupt number line. The ID numbering scheme is relevant only
>> inside the GIC, but at SoC level only the IRQ lines that entered the
>> MP core are relevant. That ID is a pure internal GIC encoding.
>>
> Exactly. For DT, the irq numbering is supposed to be local to the
> interrupt controller. So from a GIC perspective, what numbering makes sense?

The number relevant to the GIC will depend of the context.
Inside the Cortex MP, the ID# is relevant, outside, this is not the case 
anymore, because only the SPIs will be connected.

> It's also relevant to the software running on the system.

For the SW/driver case, it will be abstracted by the DT core code, so 
the real HW value should never matter.

Bottom-line: I understand your GIC centric point of view. At GIC level 
you have to handle a bunch of IDs.
And at Soc level we just want to handle a subset of them with a slightly 
different numbering scheme. So you're right, the GIC node is maybe not 
the proper place to handle that if you want the GIC code to be generic.

What is maybe just missing is a intermediate node in between to 
translate the SoC view to the GIC view.
This is probably the interrupt nexus Grant was referring to, the only 
issue today is the lack of easy support for basic translation.

>> If you refer to the GIC-400 spec [2] (Please note that I do not know
>> what that GIC is exactly...) p 25: "SPIs are triggered by events
>> generated on associated interrupt input lines. The GIC-400 can
>> support up to 480 SPIs corresponding to the external IRQS[479:0]
>> signal. The number of SPIs available depends on the implemented
>> configuration of the GIC-400. The permitted values are 0-480, in
>> steps of 32. SPIs start at ID32."
>>
>> In that case the external IRQS numbering scheme is clear: [479:0],
>> which is exactly what will be seen outside of the MP core.
>>
>> Having two interrupt controllers, one for SGIs + PPIs starting at 0
>> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
>> me a much better approach. Moreover, it will avoid exposing a cpumask
>> for SPIs.
>>
>
> Having implemented both ways already, I'm fine either way, but the
> current consensus seems to be to use the cpumask.

I missed that thread, what was the point? To have a more generic 
interface that can handle both cases?

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 3:48 PM, Rob Herring wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>>> I have another concern on a similar topic.
>>>>>>>
>>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>>> 31.
>>>>>>>
>>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>>> irq.h define,
>>>>>>
>>>>>> Those defines will not be used in the DT case. So the
>>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>>>
>>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>>> deal with that today.
>>>>>
>>>>>>> but I'm assuming that this offset calculation should be
>>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>>> HW physical number start at 0, and thus this is that value
>>>>>>> that should be in the irq binding of the device.
>>>>>>>
>>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>>> offset is always 32.
>>>>>>>
>>>>>>
>>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>>> the register layout is exactly the same as a cpu's GIC.
>>>>>
>>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>>> to have to tweak the HW number provided by the HW spec in order
>>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>>> an IP that can be potentially replaced by other one that will
>>>>> not have a GIC. In that case you will not change the IRQ
>>>>> mapping at SoC level. For example if you replace the
>>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>>> different.
>>>>>
>>>>
>>>> Is that a realistic case? That would be a new chip and new device
>>>> tree. You could argue that the whole peripheral subsystem DT
>>>> could be reused and the numbering needs to be the same. However,
>>>> there's one thing that would prevent that. The number of
>>>> interrupt cells is defined by the controller binding. So you have
>>>> to change the peripheral nodes anyway.
>>>>
>>>> It's good that OMAP is trying to standardize the peripheral
>>>> layout, but in my experience that's not something you can rely
>>>> on.
>>>>
>>>> At some point the interrupt numbering is going to differ from the
>>>> h/w documentation. If it's not in the DT, then it will be in
>>>> linux. Right now its just offset of 32, but if irqdescs get
>>>> assigned on demand as PPC is doing, then there will be no
>>>> relationship to the documentation.
>>>>
>>>>> Since that offset is dependent of the GIC internals and is not
>>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>>> IPs. And the HW spec is exposing exactly that.
>>>>>
>>>>>> Since the idea of splitting PPIs for each core out to a
>>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>>> to have more than 1 domain with a simple linear translation.
>>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>>> the translation within the gic will be completely dynamic.
>>>>>
>>>>> I think the only reason to do that is to separate internal MPU
>>>>> interrupts with the external ones that should not have a clue
>>>>> about the GIC.
>>>>
>>>> I see 2 options (besides leaving it as is):
>>>>
>>>> - Revert back to my previous binding where PPIs are a sub-node
>>>> and a different interrupt parent.
>>>>
>>>> - Use the current binding, but allow SPIs to start at 0. We can
>>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>>> an SPI, you would not be able to with this scheme.
>>>>
>>>> Either way you will still have the above issue with the cell size
>>>> changing.
>>>>
>>>
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# ->  ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.

I didn't even noticed that mess :-(
Maybe that PPI number is not that relevant in that case. It looks like 
there are using the last 4 lines (28-31).

> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.

In that case, this is indeed the case.

> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.

Maybe not, the idea is to use the scheme that is the most relevant for a 
particular subsystem. Inside the CortexA9 MP the documentation clearly 
gives the mapping based on ID#. But for SPIs, it is just written start 
as ID32.

>>> Numbering PPIs at 0 will just cause confusion as will numbering
>>> differently from SPIs. There is absolutely no mention of SPI0 or
>>> SPIx numbering in the GIC spec.
>>
>> Probably because it is the generic GIC spec that focus on internals
>> stuff only, it not an integration spec that will show how the SPIs
>> are connected to the outside world. But it is clear that the SPIs are
>> identified as 0-XXX lines outside the Cortex MP core.
>>
>
> What if the A9 or some other implementation used some SPIs internally?
> Then the external connection would be shifted differently.

Potentially yes.

> The interrupt
> binding for a peripheral is defined by it's interrupt parent (the
> interrupt controller). The number of cells and what the values mean are
> defined by the interrupt controller binding. This is independent of any
> SOC. The binding must be defined from the perspective of the interrupt
> controller.

In fact, it is dependent on both the interrupt controller binding, and 
the way the interrupt controller is connected to the SoC. It should be 
defined as well based on the interface exposed to the outside of the 
subsystem.

>> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
>> triggered by events generated on associated interrupt input lines.
>> The Interrupt Controller can support up to 224 interrupt input lines.
>> The interrupt input lines can be configured to be edge sensitive
>> (posedge) or level sensitive (high level). SPIs start at ID32.
>>
>>> All interrupt number references refer to the absolute interrupt ID,
>>> not a relative number based on the type. The fact that the
>>> Cortex-A9 implementation has interrupt lines numbered equal to the
>>> GIC SPI interrupts is an implementation detail of the A9.
>>
>>> Other cores could have different arrangement including bringing out
>>> PPI interrupts or reserving some SPIs.
>>
>> Absolutely, that's why we should not use that internal GIC convention
>> to capture external IRQ mapping. It you separate the PPI and the SPI
>> controller, you can allow any kind of internal mapping.
>>
>
> The GIC convention is the only part that is consistent and not dependent
> on the implementation.

Again, for the point of view of the GIC, but not necessarily for the SoC 
point of view.

>>> As there are many users of the GIC, it makes more sense to align
>>> with the GIC documentation rather than the documentation of 1 SOC.
>>> BTW, I have the exact same issue in our documentation.
>>
>> It is not about one SoC, this is probably done like that for every
>> other SoCs. I do not have the TRM for the other SoCs, but here is how
>> it is done in various irqs.h file today:
>>
>> - arch/arm/mach-exynos4/include/mach
>>
>> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
>> S5P_IRQ(x+16)
>>
>> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
>> S5P_IRQ(x+32)
>>
>> #define IRQ_EINT0             IRQ_SPI(16) #define IRQ_EINT1           IRQ_SPI(17) #define
>> IRQ_EINT2             IRQ_SPI(18) #define IRQ_EINT3           IRQ_SPI(19)
>>
>>
>> - arch/arm/mach-tegra/include/mach
>>
>> /* Primary Interrupt Controller */ #define INT_PRI_BASE
>> (INT_GIC_BASE + 32) #define INT_TMR1                  (INT_PRI_BASE + 0) #define
>> INT_TMR2                      (INT_PRI_BASE + 1) #define INT_RTC                              (INT_PRI_BASE + 2)
>> #define INT_I2S2                      (INT_PRI_BASE + 3)
>>
>>
>> - arch/arm/mach-ux500/include/mach
>>
>> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START                       32
>>
>> #define IRQ_MTU0              (IRQ_SHPI_START + 4)
>>
>>
>> - arch/arm/plat-omap/include/plat
>>
>> #define OMAP44XX_IRQ_GIC_START                        32
>>
>> #define OMAP44XX_IRQ_PL310                    (0 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI0                     (1 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI1                     (2 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_ELM                      (4 + OMAP44XX_IRQ_GIC_START)
>>
>>
>> Every CortexA9 based SoC have to add the 32 offset to the SoC level
>> interrupt number line. The ID numbering scheme is relevant only
>> inside the GIC, but at SoC level only the IRQ lines that entered the
>> MP core are relevant. That ID is a pure internal GIC encoding.
>>
> Exactly. For DT, the irq numbering is supposed to be local to the
> interrupt controller. So from a GIC perspective, what numbering makes sense?

The number relevant to the GIC will depend of the context.
Inside the Cortex MP, the ID# is relevant, outside, this is not the case 
anymore, because only the SPIs will be connected.

> It's also relevant to the software running on the system.

For the SW/driver case, it will be abstracted by the DT core code, so 
the real HW value should never matter.

Bottom-line: I understand your GIC centric point of view. At GIC level 
you have to handle a bunch of IDs.
And at Soc level we just want to handle a subset of them with a slightly 
different numbering scheme. So you're right, the GIC node is maybe not 
the proper place to handle that if you want the GIC code to be generic.

What is maybe just missing is a intermediate node in between to 
translate the SoC view to the GIC view.
This is probably the interrupt nexus Grant was referring to, the only 
issue today is the lack of easy support for basic translation.

>> If you refer to the GIC-400 spec [2] (Please note that I do not know
>> what that GIC is exactly...) p 25: "SPIs are triggered by events
>> generated on associated interrupt input lines. The GIC-400 can
>> support up to 480 SPIs corresponding to the external IRQS[479:0]
>> signal. The number of SPIs available depends on the implemented
>> configuration of the GIC-400. The permitted values are 0-480, in
>> steps of 32. SPIs start at ID32."
>>
>> In that case the external IRQS numbering scheme is clear: [479:0],
>> which is exactly what will be seen outside of the MP core.
>>
>> Having two interrupt controllers, one for SGIs + PPIs starting at 0
>> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
>> me a much better approach. Moreover, it will avoid exposing a cpumask
>> for SPIs.
>>
>
> Having implemented both ways already, I'm fine either way, but the
> current consensus seems to be to use the cpumask.

I missed that thread, what was the point? To have a more generic 
interface that can handle both cases?

Regards,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 3:48 PM, Rob Herring wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> On 09/15/2011 11:43 AM, Rob Herring wrote:
>>>> On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
>>>>> On 9/15/2011 3:11 PM, Rob Herring wrote:
>>>>>> On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
>>
>> [...]
>>
>>>>>>> I have another concern on a similar topic.
>>>>>>>
>>>>>>> On OMAP4 the SoC interrupts external to the MPU (SPI) have
>>>>>>> an offset of 32. Only the internal PPI are between 0 and
>>>>>>> 31.
>>>>>>>
>>>>>>> For the moment we add 32 to every SoC interrupts in the
>>>>>>> irq.h define,
>>>>>>
>>>>>> Those defines will not be used in the DT case. So the
>>>>>> question is whether to add 32 or not in the DT. Since we have
>>>>>> just a single node and a linear mapping of PPIs and SPIs, the
>>>>>> only choice is to have SPIs start at 32. And from the h/w
>>>>>> definition, SPIs always start at 32, so it's in agreement.
>>>>>
>>>>> This is a agreement inside the MPUSS, but not outside. Both
>>>>> Tegra and OMAP4 must add an offset to the HW irq number to
>>>>> deal with that today.
>>>>>
>>>>>>> but I'm assuming that this offset calculation should be
>>>>>>> done thanks to a dedicated irq domain for the SPI. The real
>>>>>>> HW physical number start at 0, and thus this is that value
>>>>>>> that should be in the irq binding of the device.
>>>>>>>
>>>>>>> So ideally we should have a irq domain for the PPI starting
>>>>>>> at 0 and another one for the SPI starting at 32. Or 32 and
>>>>>>> 64 for the exynos4 case, but it looks like the PPI/SPI
>>>>>>> offset is always 32.
>>>>>>>
>>>>>>
>>>>>> That offset of SPIs is always there. If you have a GIC as a
>>>>>> secondary controller, It will have 32 reserved interrupts and
>>>>>> the register layout is exactly the same as a cpu's GIC.
>>>>>
>>>>> Yep, but that's the GIC view and not the SoC one. My concern is
>>>>> to have to tweak the HW number provided by the HW spec in order
>>>>> to add that offset. If you look at SoC level, the MPUSS is just
>>>>> an IP that can be potentially replaced by other one that will
>>>>> not have a GIC. In that case you will not change the IRQ
>>>>> mapping at SoC level. For example if you replace the
>>>>> Dual-cortexA9 by a single CortexA8, then all the interrupts
>>>>> will have to be shifted by 32 just because the MPU subsystem is
>>>>> different.
>>>>>
>>>>
>>>> Is that a realistic case? That would be a new chip and new device
>>>> tree. You could argue that the whole peripheral subsystem DT
>>>> could be reused and the numbering needs to be the same. However,
>>>> there's one thing that would prevent that. The number of
>>>> interrupt cells is defined by the controller binding. So you have
>>>> to change the peripheral nodes anyway.
>>>>
>>>> It's good that OMAP is trying to standardize the peripheral
>>>> layout, but in my experience that's not something you can rely
>>>> on.
>>>>
>>>> At some point the interrupt numbering is going to differ from the
>>>> h/w documentation. If it's not in the DT, then it will be in
>>>> linux. Right now its just offset of 32, but if irqdescs get
>>>> assigned on demand as PPC is doing, then there will be no
>>>> relationship to the documentation.
>>>>
>>>>> Since that offset is dependent of the GIC internals and is not
>>>>> exposed outside the MPUSS, it should not be visible by the SoC
>>>>> IPs. And the HW spec is exposing exactly that.
>>>>>
>>>>>> Since the idea of splitting PPIs for each core out to a
>>>>>> flattened linux irq map has been abandoned, I see no reason
>>>>>> to have more than 1 domain with a simple linear translation.
>>>>>> Ultimately, domains will do dynamic irqdesc allocation and
>>>>>> the translation within the gic will be completely dynamic.
>>>>>
>>>>> I think the only reason to do that is to separate internal MPU
>>>>> interrupts with the external ones that should not have a clue
>>>>> about the GIC.
>>>>
>>>> I see 2 options (besides leaving it as is):
>>>>
>>>> - Revert back to my previous binding where PPIs are a sub-node
>>>> and a different interrupt parent.
>>>>
>>>> - Use the current binding, but allow SPIs to start at 0. We can
>>>> still distinguish PPIs and SPIs by the cpu mask cell. A cpu mask
>>>> of 0 is a SPI. If there was ever a reason to have a cpu mask for
>>>> an SPI, you would not be able to with this scheme.
>>>>
>>>> Either way you will still have the above issue with the cell size
>>>> changing.
>>>>
>>>
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# ->  ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.

I didn't even noticed that mess :-(
Maybe that PPI number is not that relevant in that case. It looks like 
there are using the last 4 lines (28-31).

> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.

In that case, this is indeed the case.

> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.

Maybe not, the idea is to use the scheme that is the most relevant for a 
particular subsystem. Inside the CortexA9 MP the documentation clearly 
gives the mapping based on ID#. But for SPIs, it is just written start 
as ID32.

>>> Numbering PPIs at 0 will just cause confusion as will numbering
>>> differently from SPIs. There is absolutely no mention of SPI0 or
>>> SPIx numbering in the GIC spec.
>>
>> Probably because it is the generic GIC spec that focus on internals
>> stuff only, it not an integration spec that will show how the SPIs
>> are connected to the outside world. But it is clear that the SPIs are
>> identified as 0-XXX lines outside the Cortex MP core.
>>
>
> What if the A9 or some other implementation used some SPIs internally?
> Then the external connection would be shifted differently.

Potentially yes.

> The interrupt
> binding for a peripheral is defined by it's interrupt parent (the
> interrupt controller). The number of cells and what the values mean are
> defined by the interrupt controller binding. This is independent of any
> SOC. The binding must be defined from the perspective of the interrupt
> controller.

In fact, it is dependent on both the interrupt controller binding, and 
the way the interrupt controller is connected to the SoC. It should be 
defined as well based on the interface exposed to the outside of the 
subsystem.

>> In TRM [1] page 53: Shared Peripheral Interrupts (SPI): SPIs are
>> triggered by events generated on associated interrupt input lines.
>> The Interrupt Controller can support up to 224 interrupt input lines.
>> The interrupt input lines can be configured to be edge sensitive
>> (posedge) or level sensitive (high level). SPIs start at ID32.
>>
>>> All interrupt number references refer to the absolute interrupt ID,
>>> not a relative number based on the type. The fact that the
>>> Cortex-A9 implementation has interrupt lines numbered equal to the
>>> GIC SPI interrupts is an implementation detail of the A9.
>>
>>> Other cores could have different arrangement including bringing out
>>> PPI interrupts or reserving some SPIs.
>>
>> Absolutely, that's why we should not use that internal GIC convention
>> to capture external IRQ mapping. It you separate the PPI and the SPI
>> controller, you can allow any kind of internal mapping.
>>
>
> The GIC convention is the only part that is consistent and not dependent
> on the implementation.

Again, for the point of view of the GIC, but not necessarily for the SoC 
point of view.

>>> As there are many users of the GIC, it makes more sense to align
>>> with the GIC documentation rather than the documentation of 1 SOC.
>>> BTW, I have the exact same issue in our documentation.
>>
>> It is not about one SoC, this is probably done like that for every
>> other SoCs. I do not have the TRM for the other SoCs, but here is how
>> it is done in various irqs.h file today:
>>
>> - arch/arm/mach-exynos4/include/mach
>>
>> /* PPI: Private Peripheral Interrupt */ #define IRQ_PPI(x)
>> S5P_IRQ(x+16)
>>
>> /* SPI: Shared Peripheral Interrupt */ #define IRQ_SPI(x)
>> S5P_IRQ(x+32)
>>
>> #define IRQ_EINT0             IRQ_SPI(16) #define IRQ_EINT1           IRQ_SPI(17) #define
>> IRQ_EINT2             IRQ_SPI(18) #define IRQ_EINT3           IRQ_SPI(19)
>>
>>
>> - arch/arm/mach-tegra/include/mach
>>
>> /* Primary Interrupt Controller */ #define INT_PRI_BASE
>> (INT_GIC_BASE + 32) #define INT_TMR1                  (INT_PRI_BASE + 0) #define
>> INT_TMR2                      (INT_PRI_BASE + 1) #define INT_RTC                              (INT_PRI_BASE + 2)
>> #define INT_I2S2                      (INT_PRI_BASE + 3)
>>
>>
>> - arch/arm/mach-ux500/include/mach
>>
>> /* Shared Peripheral Interrupt (SHPI) */ #define IRQ_SHPI_START                       32
>>
>> #define IRQ_MTU0              (IRQ_SHPI_START + 4)
>>
>>
>> - arch/arm/plat-omap/include/plat
>>
>> #define OMAP44XX_IRQ_GIC_START                        32
>>
>> #define OMAP44XX_IRQ_PL310                    (0 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI0                     (1 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_CTI1                     (2 + OMAP44XX_IRQ_GIC_START) #define
>> OMAP44XX_IRQ_ELM                      (4 + OMAP44XX_IRQ_GIC_START)
>>
>>
>> Every CortexA9 based SoC have to add the 32 offset to the SoC level
>> interrupt number line. The ID numbering scheme is relevant only
>> inside the GIC, but at SoC level only the IRQ lines that entered the
>> MP core are relevant. That ID is a pure internal GIC encoding.
>>
> Exactly. For DT, the irq numbering is supposed to be local to the
> interrupt controller. So from a GIC perspective, what numbering makes sense?

The number relevant to the GIC will depend of the context.
Inside the Cortex MP, the ID# is relevant, outside, this is not the case 
anymore, because only the SPIs will be connected.

> It's also relevant to the software running on the system.

For the SW/driver case, it will be abstracted by the DT core code, so 
the real HW value should never matter.

Bottom-line: I understand your GIC centric point of view. At GIC level 
you have to handle a bunch of IDs.
And at Soc level we just want to handle a subset of them with a slightly 
different numbering scheme. So you're right, the GIC node is maybe not 
the proper place to handle that if you want the GIC code to be generic.

What is maybe just missing is a intermediate node in between to 
translate the SoC view to the GIC view.
This is probably the interrupt nexus Grant was referring to, the only 
issue today is the lack of easy support for basic translation.

>> If you refer to the GIC-400 spec [2] (Please note that I do not know
>> what that GIC is exactly...) p 25: "SPIs are triggered by events
>> generated on associated interrupt input lines. The GIC-400 can
>> support up to 480 SPIs corresponding to the external IRQS[479:0]
>> signal. The number of SPIs available depends on the implemented
>> configuration of the GIC-400. The permitted values are 0-480, in
>> steps of 32. SPIs start at ID32."
>>
>> In that case the external IRQS numbering scheme is clear: [479:0],
>> which is exactly what will be seen outside of the MP core.
>>
>> Having two interrupt controllers, one for SGIs + PPIs starting at 0
>> (hwirq#) and another one from SPIs starting at 32 (hwirq#), seems to
>> me a much better approach. Moreover, it will avoid exposing a cpumask
>> for SPIs.
>>
>
> Having implemented both ways already, I'm fine either way, but the
> current consensus seems to be to use the cpumask.

I missed that thread, what was the point? To have a more generic 
interface that can handle both cases?

Regards,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Mon, Sep 19, 2011 at 02:09:46PM +0200, Cousson, Benoit wrote:
> Every CortexA9 based SoC have to add the 32 offset to the SoC level
> interrupt number line. The ID numbering scheme is relevant only inside
> the GIC, but at SoC level only the IRQ lines that entered the MP core
> are relevant. That ID is a pure internal GIC encoding.

As far as SPIs go, I think what should be done is that the DT should
refer to a SPI phandle plus the SPI number, and be done with just that.

The point as to whether SoCs internally use SPIs themselves is a complete
distraction - if they're using SPIs internally then we _also_ need some
way for the on-SoC peripherals to refer to them too.

What the GIC exports are 16 PPIs per CPU, 16 SGIs and N SPIs.  That's what
we should be modelling for the GIC, not something else.  So peripherals
connect to an SPI numbered N where N >= 0.

How we want SPIs to map to Linux IRQ numbers is the issue, and as things
stand at present, we want SPI0 to map to IRQ32 on all platforms where the
GIC is the root, to avoid any unnecessary complexity (because the hardware
tells us that SPI0 gives us ID32 in the interrupt acknowledge register.)
Doing anything else requires computation or a lookup table, and we shouldn't
be doing that kind of thing unless there's a real reason to do so (there
isn't, especially with sparse irq support.)

As far as PPIs go, support for that is still being worked on, and most of
that at present does not go through genirq stuff (and it isn't relevant to
use the standard genirq interfaces for PPIs _anyway_.)

SGIs don't use genirq in any way, and are used for SMP IPIs.  That's
completely separate from the way IRQs are used - they're not connected
to devices at all. (They're provided as an inter-processor communication
method.)  So forget SGIs.  They may apparantly occupy IRQ IDs 0-15, but
reality is they leave those IDs unused, IRQs 0-15 are not requestable,
which is a definite *good* thing.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Mon, Sep 19, 2011 at 02:09:46PM +0200, Cousson, Benoit wrote:
> Every CortexA9 based SoC have to add the 32 offset to the SoC level
> interrupt number line. The ID numbering scheme is relevant only inside
> the GIC, but at SoC level only the IRQ lines that entered the MP core
> are relevant. That ID is a pure internal GIC encoding.

As far as SPIs go, I think what should be done is that the DT should
refer to a SPI phandle plus the SPI number, and be done with just that.

The point as to whether SoCs internally use SPIs themselves is a complete
distraction - if they're using SPIs internally then we _also_ need some
way for the on-SoC peripherals to refer to them too.

What the GIC exports are 16 PPIs per CPU, 16 SGIs and N SPIs.  That's what
we should be modelling for the GIC, not something else.  So peripherals
connect to an SPI numbered N where N >= 0.

How we want SPIs to map to Linux IRQ numbers is the issue, and as things
stand at present, we want SPI0 to map to IRQ32 on all platforms where the
GIC is the root, to avoid any unnecessary complexity (because the hardware
tells us that SPI0 gives us ID32 in the interrupt acknowledge register.)
Doing anything else requires computation or a lookup table, and we shouldn't
be doing that kind of thing unless there's a real reason to do so (there
isn't, especially with sparse irq support.)

As far as PPIs go, support for that is still being worked on, and most of
that at present does not go through genirq stuff (and it isn't relevant to
use the standard genirq interfaces for PPIs _anyway_.)

SGIs don't use genirq in any way, and are used for SMP IPIs.  That's
completely separate from the way IRQs are used - they're not connected
to devices at all. (They're provided as an inter-processor communication
method.)  So forget SGIs.  They may apparantly occupy IRQ IDs 0-15, but
reality is they leave those IDs unused, IRQs 0-15 are not requestable,
which is a definite *good* thing.

[PATCH 5/5] ARM: gic: add OF based initialization

[Russell King - ARM Linux]

On Mon, Sep 19, 2011 at 02:09:46PM +0200, Cousson, Benoit wrote:
> Every CortexA9 based SoC have to add the 32 offset to the SoC level
> interrupt number line. The ID numbering scheme is relevant only inside
> the GIC, but at SoC level only the IRQ lines that entered the MP core
> are relevant. That ID is a pure internal GIC encoding.

As far as SPIs go, I think what should be done is that the DT should
refer to a SPI phandle plus the SPI number, and be done with just that.

The point as to whether SoCs internally use SPIs themselves is a complete
distraction - if they're using SPIs internally then we _also_ need some
way for the on-SoC peripherals to refer to them too.

What the GIC exports are 16 PPIs per CPU, 16 SGIs and N SPIs.  That's what
we should be modelling for the GIC, not something else.  So peripherals
connect to an SPI numbered N where N >= 0.

How we want SPIs to map to Linux IRQ numbers is the issue, and as things
stand at present, we want SPI0 to map to IRQ32 on all platforms where the
GIC is the root, to avoid any unnecessary complexity (because the hardware
tells us that SPI0 gives us ID32 in the interrupt acknowledge register.)
Doing anything else requires computation or a lookup table, and we shouldn't
be doing that kind of thing unless there's a real reason to do so (there
isn't, especially with sparse irq support.)

As far as PPIs go, support for that is still being worked on, and most of
that at present does not go through genirq stuff (and it isn't relevant to
use the standard genirq interfaces for PPIs _anyway_.)

SGIs don't use genirq in any way, and are used for SMP IPIs.  That's
completely separate from the way IRQs are used - they're not connected
to devices at all. (They're provided as an inter-processor communication
method.)  So forget SGIs.  They may apparantly occupy IRQ IDs 0-15, but
reality is they leave those IDs unused, IRQs 0-15 are not requestable,
which is a definite *good* thing.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 7:33 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
>> Since the cpumask is not relevant for the SPI, maybe having two
>> interrupt controllers will be more relevant. Or maybe 3, since there is
>> some SGIs as well.
>
> I don't think anyone uses SGIs outside of the common SMP code.
> Therefore they're handled entirely separately for the root GIC.
>
> (If there's two GICs - some platforms do have two - then the SGIs on
> the non-root GIC are unused.)

...and since SGIs aren't external HW inputs to the GIC, there really
isn't any need to reflect them in the GIC DT binding.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 7:33 AM, Russell King - ARM Linux
<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
>> Since the cpumask is not relevant for the SPI, maybe having two
>> interrupt controllers will be more relevant. Or maybe 3, since there is
>> some SGIs as well.
>
> I don't think anyone uses SGIs outside of the common SMP code.
> Therefore they're handled entirely separately for the root GIC.
>
> (If there's two GICs - some platforms do have two - then the SGIs on
> the non-root GIC are unused.)

...and since SGIs aren't external HW inputs to the GIC, there really
isn't any need to reflect them in the GIC DT binding.

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 7:33 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
>> Since the cpumask is not relevant for the SPI, maybe having two
>> interrupt controllers will be more relevant. Or maybe 3, since there is
>> some SGIs as well.
>
> I don't think anyone uses SGIs outside of the common SMP code.
> Therefore they're handled entirely separately for the root GIC.
>
> (If there's two GICs - some platforms do have two - then the SGIs on
> the non-root GIC are unused.)

...and since SGIs aren't external HW inputs to the GIC, there really
isn't any need to reflect them in the GIC DT binding.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Sun, Sep 18, 2011 at 04:23:40PM -0500, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
> > I see 2 options (besides leaving it as is):
> > 
> > - Revert back to my previous binding where PPIs are a sub-node and a
> > different interrupt parent.
> > 
> > - Use the current binding, but allow SPIs to start at 0. We can still
> > distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> > SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> > not be able to with this scheme.
> > 
> > Either way you will still have the above issue with the cell size changing.
> > 
> 
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type.

Hi Rob,

See here[1] and [2] (figures 3.14 and 3.16).  In both cases, there is
clearly a reference to PPI numbering from 0-15 and SPI numbering from
0-987 (as inputs to the distributor block).

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Bhacbfdb.html
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Cihebcbg.html

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Sun, Sep 18, 2011 at 04:23:40PM -0500, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
> > I see 2 options (besides leaving it as is):
> > 
> > - Revert back to my previous binding where PPIs are a sub-node and a
> > different interrupt parent.
> > 
> > - Use the current binding, but allow SPIs to start at 0. We can still
> > distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> > SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> > not be able to with this scheme.
> > 
> > Either way you will still have the above issue with the cell size changing.
> > 
> 
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type.

Hi Rob,

See here[1] and [2] (figures 3.14 and 3.16).  In both cases, there is
clearly a reference to PPI numbering from 0-15 and SPI numbering from
0-987 (as inputs to the distributor block).

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Bhacbfdb.html
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Cihebcbg.html

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Sun, Sep 18, 2011 at 04:23:40PM -0500, Rob Herring wrote:
> On 09/15/2011 11:43 AM, Rob Herring wrote:
> > I see 2 options (besides leaving it as is):
> > 
> > - Revert back to my previous binding where PPIs are a sub-node and a
> > different interrupt parent.
> > 
> > - Use the current binding, but allow SPIs to start at 0. We can still
> > distinguish PPIs and SPIs by the cpu mask cell. A cpu mask of 0 is a
> > SPI. If there was ever a reason to have a cpu mask for an SPI, you would
> > not be able to with this scheme.
> > 
> > Either way you will still have the above issue with the cell size changing.
> > 
> 
> I was headed down the path of implementing the 2nd option above, but had
> a dilemma. What would be the numbering base for PPIs in this case?
> Should it be 0 in the DT as proposed for SPIs or does it stay at 16?
> Numbering PPIs at 0 will just cause confusion as will numbering
> differently from SPIs. There is absolutely no mention of SPI0 or SPIx
> numbering in the GIC spec. All interrupt number references refer to the
> absolute interrupt ID, not a relative number based on the type.

Hi Rob,

See here[1] and [2] (figures 3.14 and 3.16).  In both cases, there is
clearly a reference to PPI numbering from 0-15 and SPI numbering from
0-987 (as inputs to the distributor block).

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Bhacbfdb.html
[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0416b/Cihebcbg.html

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.
> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.
>
> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.

Hmmm, it seems to me that some orthogonal issues are getting
conflated.  Specifically, the binding vs. what the GIC driver using
internally.  For my own understanding, let me see if I can summarize
and clarify the problem.

Each GIC IRQ is represented in 5 different ways:
1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
2) The DT binding to represent the connection.
3) The Interrupt ID as specified by the GIC architecture reference[1]
(SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
4) The internal HWIRQ representation used by the GIC driver
5) The Linux VIRQ number that #4 maps to.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html

Some thoughts:
- Generally the DT binding (#2) should reflect the HW view of the
system (#1) since that is the number most likely to be represented in
hardware manuals.  The interrupt ID is an internal detail of the GIC,
and isn't really exposed in the block diagram of the hardware.
- Presumably it is preferable for the GIC to directly use the
Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
efficient from an interrupt handling perspective, and indeed this is
currently what the GIC driver does.
- Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
(#3/#4) is trivial, and easily managed by the GIC's irq_domain.
- Though not necessarily as trivial, the mapping between Linux VIRQ
and HWIRQ is not fixed, and when migrating to DT it should be assumed
to be assigned at runtime.  Perhaps not so important for a core IRQ
controller like the GIC (as opposed to an i2c irq expander), but
assuming an fixed offset still should be avoided.  We may still force
a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
necessary and the driver still needs to support remapping for a
secondary GIC.

So, for the GIC DT binding, I'm inclined to agree with Benoit that the
binding should reflect the hardware connections, not the values used
by software for decoding IRQs.  Also, I see absolutely no need to use
separate nodes for each GIC interrupt space.  The DT interrupt
specifier number space can more than handle the features of the GIC in
a clear and concise manor.  So, here's my counter proposal for a GIC
bindings (using Rob's text as the starting point):

----

* ARM Generic Interrupt Controller

ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).

Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.

Main node required properties:

- compatible : should be one of:
       "arm,cortex-a9-gic"
       "arm,arm11mp-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
  interrupt source.  The type shall be a <u32> and the value shall be 3.

  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
  The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987].  PPI interrupts are in the
range [0-15].
  The 3rd cell is the flags, encoded as follows:
        bits[3:0] trigger type and level flags.
                    1 = low-to-high edge triggered
                    2 = high-to-low edge triggered
                    4 = active high level-sensitive
                    8 = active low level-sensitive
        bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
each of the 8 possible cpus attached to the GIC.  A bit set to '1'
indicated the interrupt is wired to that CPU.  Only valid for PPI
interrupts.

(Alternately, if there is no need for a CPU mask because PPI
interrupts will never be wired to more than one CPU, then it would be
better to encode the CPU number into the second cell with the SPI
number).

- reg : Specifies base physical address(s) and size of the GIC registers. The
  first 2 values are the GIC distributor register base and size. The 2nd 2
  values are the GIC cpu interface register base and size.

Optional
- interrupts   : Interrupt source of the parent interrupt controller. Only
  present on secondary GICs.

Example:
       intc: interrupt-controller@fff11000 {
               compatible = "arm,cortex-a9-gic";
               #interrupt-cells = <3>;
               #address-cells = <1>;
               interrupt-controller;
               reg = <0xfff11000 0x1000>,
                     <0xfff10100 0x100>;
       };

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.
> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.
>
> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.

Hmmm, it seems to me that some orthogonal issues are getting
conflated.  Specifically, the binding vs. what the GIC driver using
internally.  For my own understanding, let me see if I can summarize
and clarify the problem.

Each GIC IRQ is represented in 5 different ways:
1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
2) The DT binding to represent the connection.
3) The Interrupt ID as specified by the GIC architecture reference[1]
(SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
4) The internal HWIRQ representation used by the GIC driver
5) The Linux VIRQ number that #4 maps to.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html

Some thoughts:
- Generally the DT binding (#2) should reflect the HW view of the
system (#1) since that is the number most likely to be represented in
hardware manuals.  The interrupt ID is an internal detail of the GIC,
and isn't really exposed in the block diagram of the hardware.
- Presumably it is preferable for the GIC to directly use the
Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
efficient from an interrupt handling perspective, and indeed this is
currently what the GIC driver does.
- Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
(#3/#4) is trivial, and easily managed by the GIC's irq_domain.
- Though not necessarily as trivial, the mapping between Linux VIRQ
and HWIRQ is not fixed, and when migrating to DT it should be assumed
to be assigned at runtime.  Perhaps not so important for a core IRQ
controller like the GIC (as opposed to an i2c irq expander), but
assuming an fixed offset still should be avoided.  We may still force
a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
necessary and the driver still needs to support remapping for a
secondary GIC.

So, for the GIC DT binding, I'm inclined to agree with Benoit that the
binding should reflect the hardware connections, not the values used
by software for decoding IRQs.  Also, I see absolutely no need to use
separate nodes for each GIC interrupt space.  The DT interrupt
specifier number space can more than handle the features of the GIC in
a clear and concise manor.  So, here's my counter proposal for a GIC
bindings (using Rob's text as the starting point):

----

* ARM Generic Interrupt Controller

ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).

Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.

Main node required properties:

- compatible : should be one of:
       "arm,cortex-a9-gic"
       "arm,arm11mp-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
  interrupt source.  The type shall be a <u32> and the value shall be 3.

  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
  The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987].  PPI interrupts are in the
range [0-15].
  The 3rd cell is the flags, encoded as follows:
        bits[3:0] trigger type and level flags.
                    1 = low-to-high edge triggered
                    2 = high-to-low edge triggered
                    4 = active high level-sensitive
                    8 = active low level-sensitive
        bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
each of the 8 possible cpus attached to the GIC.  A bit set to '1'
indicated the interrupt is wired to that CPU.  Only valid for PPI
interrupts.

(Alternately, if there is no need for a CPU mask because PPI
interrupts will never be wired to more than one CPU, then it would be
better to encode the CPU number into the second cell with the SPI
number).

- reg : Specifies base physical address(s) and size of the GIC registers. The
  first 2 values are the GIC distributor register base and size. The 2nd 2
  values are the GIC cpu interface register base and size.

Optional
- interrupts   : Interrupt source of the parent interrupt controller. Only
  present on secondary GICs.

Example:
       intc: interrupt-controller@fff11000 {
               compatible = "arm,cortex-a9-gic";
               #interrupt-cells = <3>;
               #address-cells = <1>;
               interrupt-controller;
               reg = <0xfff11000 0x1000>,
                     <0xfff10100 0x100>;
       };

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>> I was headed down the path of implementing the 2nd option above,
>>> but had a dilemma. What would be the numbering base for PPIs in
>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>> stay at 16?
>>
>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>> processor has its own private timers that can generate interrupts,
>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>> its own watchdog timers that can generate interrupts, using ID30.
>>
>> So in that case, it can makes sense to use the ID. But it is
>> interesting to note that the PPI is identified with a 0 based index
>> number.
>>
> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
> for the timer interrupt. The first would match 0 based SPI convention.
> The last 2 would both match the documentation. We could never use 2 as
> this will for sure be different and the GIC code will have no way to
> know how to do the translation to ID. The only sane choice is using the
> ID as you say.
>
> But you can't have it both ways. It does not make sense to use the ID
> for some interrupts and a different scheme for others.

Hmmm, it seems to me that some orthogonal issues are getting
conflated.  Specifically, the binding vs. what the GIC driver using
internally.  For my own understanding, let me see if I can summarize
and clarify the problem.

Each GIC IRQ is represented in 5 different ways:
1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
2) The DT binding to represent the connection.
3) The Interrupt ID as specified by the GIC architecture reference[1]
(SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
4) The internal HWIRQ representation used by the GIC driver
5) The Linux VIRQ number that #4 maps to.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html

Some thoughts:
- Generally the DT binding (#2) should reflect the HW view of the
system (#1) since that is the number most likely to be represented in
hardware manuals.  The interrupt ID is an internal detail of the GIC,
and isn't really exposed in the block diagram of the hardware.
- Presumably it is preferable for the GIC to directly use the
Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
efficient from an interrupt handling perspective, and indeed this is
currently what the GIC driver does.
- Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
(#3/#4) is trivial, and easily managed by the GIC's irq_domain.
- Though not necessarily as trivial, the mapping between Linux VIRQ
and HWIRQ is not fixed, and when migrating to DT it should be assumed
to be assigned at runtime.  Perhaps not so important for a core IRQ
controller like the GIC (as opposed to an i2c irq expander), but
assuming an fixed offset still should be avoided.  We may still force
a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
necessary and the driver still needs to support remapping for a
secondary GIC.

So, for the GIC DT binding, I'm inclined to agree with Benoit that the
binding should reflect the hardware connections, not the values used
by software for decoding IRQs.  Also, I see absolutely no need to use
separate nodes for each GIC interrupt space.  The DT interrupt
specifier number space can more than handle the features of the GIC in
a clear and concise manor.  So, here's my counter proposal for a GIC
bindings (using Rob's text as the starting point):

----

* ARM Generic Interrupt Controller

ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
generated interrupts (SGI).

Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
Secondary GICs are cascaded into the upward interrupt controller and do not
have PPIs or SGIs.

Main node required properties:

- compatible : should be one of:
       "arm,cortex-a9-gic"
       "arm,arm11mp-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
  interrupt source.  The type shall be a <u32> and the value shall be 3.

  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts.
  The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987].  PPI interrupts are in the
range [0-15].
  The 3rd cell is the flags, encoded as follows:
        bits[3:0] trigger type and level flags.
                    1 = low-to-high edge triggered
                    2 = high-to-low edge triggered
                    4 = active high level-sensitive
                    8 = active low level-sensitive
        bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
each of the 8 possible cpus attached to the GIC.  A bit set to '1'
indicated the interrupt is wired to that CPU.  Only valid for PPI
interrupts.

(Alternately, if there is no need for a CPU mask because PPI
interrupts will never be wired to more than one CPU, then it would be
better to encode the CPU number into the second cell with the SPI
number).

- reg : Specifies base physical address(s) and size of the GIC registers. The
  first 2 values are the GIC distributor register base and size. The 2nd 2
  values are the GIC cpu interface register base and size.

Optional
- interrupts   : Interrupt source of the parent interrupt controller. Only
  present on secondary GICs.

Example:
       intc: interrupt-controller at fff11000 {
               compatible = "arm,cortex-a9-gic";
               #interrupt-cells = <3>;
               #address-cells = <1>;
               interrupt-controller;
               reg = <0xfff11000 0x1000>,
                     <0xfff10100 0x100>;
       };

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/19/2011 04:14 PM, Grant Likely wrote:
> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>> I was headed down the path of implementing the 2nd option above,
>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>> stay at 16?
>>>
>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>> processor has its own private timers that can generate interrupts,
>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>> its own watchdog timers that can generate interrupts, using ID30.
>>>
>>> So in that case, it can makes sense to use the ID. But it is
>>> interesting to note that the PPI is identified with a 0 based index
>>> number.
>>>
>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>> for the timer interrupt. The first would match 0 based SPI convention.
>> The last 2 would both match the documentation. We could never use 2 as
>> this will for sure be different and the GIC code will have no way to
>> know how to do the translation to ID. The only sane choice is using the
>> ID as you say.
>>
>> But you can't have it both ways. It does not make sense to use the ID
>> for some interrupts and a different scheme for others.
> 
> Hmmm, it seems to me that some orthogonal issues are getting
> conflated.  Specifically, the binding vs. what the GIC driver using
> internally.  For my own understanding, let me see if I can summarize
> and clarify the problem.
> 
> Each GIC IRQ is represented in 5 different ways:
> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
> 2) The DT binding to represent the connection.
> 3) The Interrupt ID as specified by the GIC architecture reference[1]
> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
> 4) The internal HWIRQ representation used by the GIC driver
> 5) The Linux VIRQ number that #4 maps to.
> 
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
> 
> Some thoughts:
> - Generally the DT binding (#2) should reflect the HW view of the
> system (#1) since that is the number most likely to be represented in
> hardware manuals.  The interrupt ID is an internal detail of the GIC,
> and isn't really exposed in the block diagram of the hardware.
> - Presumably it is preferable for the GIC to directly use the
> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
> efficient from an interrupt handling perspective, and indeed this is
> currently what the GIC driver does.
> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
> - Though not necessarily as trivial, the mapping between Linux VIRQ
> and HWIRQ is not fixed, and when migrating to DT it should be assumed
> to be assigned at runtime.  Perhaps not so important for a core IRQ
> controller like the GIC (as opposed to an i2c irq expander), but
> assuming an fixed offset still should be avoided.  We may still force
> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
> necessary and the driver still needs to support remapping for a
> secondary GIC.

The irq base is dynamic in my series, but is typically still GIC ID =
VIRQ for a primary GIC for now. A platform can adjust this with
irq_alloc_descs if necessary (but recommended not to of course).

> 
> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
> binding should reflect the hardware connections, not the values used
> by software for decoding IRQs.  Also, I see absolutely no need to use
> separate nodes for each GIC interrupt space.  The DT interrupt
> specifier number space can more than handle the features of the GIC in
> a clear and concise manor.  So, here's my counter proposal for a GIC
> bindings (using Rob's text as the starting point):
> 
> ----
> 
> * ARM Generic Interrupt Controller
> 
> ARM SMP cores are often associated with a GIC, providing per processor
> interrupts (PPI), shared processor interrupts (SPI) and software
> generated interrupts (SGI).
> 
> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> Secondary GICs are cascaded into the upward interrupt controller and do not
> have PPIs or SGIs.
> 
> Main node required properties:
> 
> - compatible : should be one of:
>        "arm,cortex-a9-gic"
>        "arm,arm11mp-gic"
> - interrupt-controller : Identifies the node as an interrupt controller
> - #interrupt-cells : Specifies the number of cells needed to encode an
>   interrupt source.  The type shall be a <u32> and the value shall be 3.
> 
>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> interrupts.
>   The 2nd cell contains the interrupt number for the interrupt type.
> SPI interrupts are in the range [0-987].  PPI interrupts are in the
> range [0-15].
>   The 3rd cell is the flags, encoded as follows:
>         bits[3:0] trigger type and level flags.
>                     1 = low-to-high edge triggered
>                     2 = high-to-low edge triggered
>                     4 = active high level-sensitive
>                     8 = active low level-sensitive
>         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
> indicated the interrupt is wired to that CPU.  Only valid for PPI
> interrupts.
> 
How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
drop the first cell.

> (Alternately, if there is no need for a CPU mask because PPI
> interrupts will never be wired to more than one CPU, then it would be
> better to encode the CPU number into the second cell with the SPI
> number).
You meant PPI number, right?                                    ^^^

The common case at least on the A9 is a PPI is routed to all cores. QC
is different though. This was discussed previously. Basically, anything
is possible here, so the mask is needed for sure.

Overall I'm fine with this and just happy to have some conclusion. I
will send out an updated series if there are no further comments.

Rob

> 
> - reg : Specifies base physical address(s) and size of the GIC registers. The
>   first 2 values are the GIC distributor register base and size. The 2nd 2
>   values are the GIC cpu interface register base and size.
> 
> Optional
> - interrupts   : Interrupt source of the parent interrupt controller. Only
>   present on secondary GICs.
> 
> Example:
>        intc: interrupt-controller@fff11000 {
>                compatible = "arm,cortex-a9-gic";
>                #interrupt-cells = <3>;
>                #address-cells = <1>;
>                interrupt-controller;
>                reg = <0xfff11000 0x1000>,
>                      <0xfff10100 0x100>;
>        };

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/19/2011 04:14 PM, Grant Likely wrote:
> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>> I was headed down the path of implementing the 2nd option above,
>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>> stay at 16?
>>>
>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>> processor has its own private timers that can generate interrupts,
>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>> its own watchdog timers that can generate interrupts, using ID30.
>>>
>>> So in that case, it can makes sense to use the ID. But it is
>>> interesting to note that the PPI is identified with a 0 based index
>>> number.
>>>
>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>> for the timer interrupt. The first would match 0 based SPI convention.
>> The last 2 would both match the documentation. We could never use 2 as
>> this will for sure be different and the GIC code will have no way to
>> know how to do the translation to ID. The only sane choice is using the
>> ID as you say.
>>
>> But you can't have it both ways. It does not make sense to use the ID
>> for some interrupts and a different scheme for others.
> 
> Hmmm, it seems to me that some orthogonal issues are getting
> conflated.  Specifically, the binding vs. what the GIC driver using
> internally.  For my own understanding, let me see if I can summarize
> and clarify the problem.
> 
> Each GIC IRQ is represented in 5 different ways:
> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
> 2) The DT binding to represent the connection.
> 3) The Interrupt ID as specified by the GIC architecture reference[1]
> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
> 4) The internal HWIRQ representation used by the GIC driver
> 5) The Linux VIRQ number that #4 maps to.
> 
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
> 
> Some thoughts:
> - Generally the DT binding (#2) should reflect the HW view of the
> system (#1) since that is the number most likely to be represented in
> hardware manuals.  The interrupt ID is an internal detail of the GIC,
> and isn't really exposed in the block diagram of the hardware.
> - Presumably it is preferable for the GIC to directly use the
> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
> efficient from an interrupt handling perspective, and indeed this is
> currently what the GIC driver does.
> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
> - Though not necessarily as trivial, the mapping between Linux VIRQ
> and HWIRQ is not fixed, and when migrating to DT it should be assumed
> to be assigned at runtime.  Perhaps not so important for a core IRQ
> controller like the GIC (as opposed to an i2c irq expander), but
> assuming an fixed offset still should be avoided.  We may still force
> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
> necessary and the driver still needs to support remapping for a
> secondary GIC.

The irq base is dynamic in my series, but is typically still GIC ID =
VIRQ for a primary GIC for now. A platform can adjust this with
irq_alloc_descs if necessary (but recommended not to of course).

> 
> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
> binding should reflect the hardware connections, not the values used
> by software for decoding IRQs.  Also, I see absolutely no need to use
> separate nodes for each GIC interrupt space.  The DT interrupt
> specifier number space can more than handle the features of the GIC in
> a clear and concise manor.  So, here's my counter proposal for a GIC
> bindings (using Rob's text as the starting point):
> 
> ----
> 
> * ARM Generic Interrupt Controller
> 
> ARM SMP cores are often associated with a GIC, providing per processor
> interrupts (PPI), shared processor interrupts (SPI) and software
> generated interrupts (SGI).
> 
> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> Secondary GICs are cascaded into the upward interrupt controller and do not
> have PPIs or SGIs.
> 
> Main node required properties:
> 
> - compatible : should be one of:
>        "arm,cortex-a9-gic"
>        "arm,arm11mp-gic"
> - interrupt-controller : Identifies the node as an interrupt controller
> - #interrupt-cells : Specifies the number of cells needed to encode an
>   interrupt source.  The type shall be a <u32> and the value shall be 3.
> 
>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> interrupts.
>   The 2nd cell contains the interrupt number for the interrupt type.
> SPI interrupts are in the range [0-987].  PPI interrupts are in the
> range [0-15].
>   The 3rd cell is the flags, encoded as follows:
>         bits[3:0] trigger type and level flags.
>                     1 = low-to-high edge triggered
>                     2 = high-to-low edge triggered
>                     4 = active high level-sensitive
>                     8 = active low level-sensitive
>         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
> indicated the interrupt is wired to that CPU.  Only valid for PPI
> interrupts.
> 
How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
drop the first cell.

> (Alternately, if there is no need for a CPU mask because PPI
> interrupts will never be wired to more than one CPU, then it would be
> better to encode the CPU number into the second cell with the SPI
> number).
You meant PPI number, right?                                    ^^^

The common case at least on the A9 is a PPI is routed to all cores. QC
is different though. This was discussed previously. Basically, anything
is possible here, so the mask is needed for sure.

Overall I'm fine with this and just happy to have some conclusion. I
will send out an updated series if there are no further comments.

Rob

> 
> - reg : Specifies base physical address(s) and size of the GIC registers. The
>   first 2 values are the GIC distributor register base and size. The 2nd 2
>   values are the GIC cpu interface register base and size.
> 
> Optional
> - interrupts   : Interrupt source of the parent interrupt controller. Only
>   present on secondary GICs.
> 
> Example:
>        intc: interrupt-controller@fff11000 {
>                compatible = "arm,cortex-a9-gic";
>                #interrupt-cells = <3>;
>                #address-cells = <1>;
>                interrupt-controller;
>                reg = <0xfff11000 0x1000>,
>                      <0xfff10100 0x100>;
>        };

[PATCH 5/5] ARM: gic: add OF based initialization

[Rob Herring]

On 09/19/2011 04:14 PM, Grant Likely wrote:
> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring <robherring2@gmail.com> wrote:
>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>> I was headed down the path of implementing the 2nd option above,
>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>> stay at 16?
>>>
>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>> to the CortexA9 MP core TRM [1], you can see that the PPI# -> ID#
>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>> processor has its own private timers that can generate interrupts,
>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>> its own watchdog timers that can generate interrupts, using ID30.
>>>
>>> So in that case, it can makes sense to use the ID. But it is
>>> interesting to note that the PPI is identified with a 0 based index
>>> number.
>>>
>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>> for the timer interrupt. The first would match 0 based SPI convention.
>> The last 2 would both match the documentation. We could never use 2 as
>> this will for sure be different and the GIC code will have no way to
>> know how to do the translation to ID. The only sane choice is using the
>> ID as you say.
>>
>> But you can't have it both ways. It does not make sense to use the ID
>> for some interrupts and a different scheme for others.
> 
> Hmmm, it seems to me that some orthogonal issues are getting
> conflated.  Specifically, the binding vs. what the GIC driver using
> internally.  For my own understanding, let me see if I can summarize
> and clarify the problem.
> 
> Each GIC IRQ is represented in 5 different ways:
> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
> 2) The DT binding to represent the connection.
> 3) The Interrupt ID as specified by the GIC architecture reference[1]
> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
> 4) The internal HWIRQ representation used by the GIC driver
> 5) The Linux VIRQ number that #4 maps to.
> 
> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
> 
> Some thoughts:
> - Generally the DT binding (#2) should reflect the HW view of the
> system (#1) since that is the number most likely to be represented in
> hardware manuals.  The interrupt ID is an internal detail of the GIC,
> and isn't really exposed in the block diagram of the hardware.
> - Presumably it is preferable for the GIC to directly use the
> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
> efficient from an interrupt handling perspective, and indeed this is
> currently what the GIC driver does.
> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
> - Though not necessarily as trivial, the mapping between Linux VIRQ
> and HWIRQ is not fixed, and when migrating to DT it should be assumed
> to be assigned at runtime.  Perhaps not so important for a core IRQ
> controller like the GIC (as opposed to an i2c irq expander), but
> assuming an fixed offset still should be avoided.  We may still force
> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
> necessary and the driver still needs to support remapping for a
> secondary GIC.

The irq base is dynamic in my series, but is typically still GIC ID =
VIRQ for a primary GIC for now. A platform can adjust this with
irq_alloc_descs if necessary (but recommended not to of course).

> 
> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
> binding should reflect the hardware connections, not the values used
> by software for decoding IRQs.  Also, I see absolutely no need to use
> separate nodes for each GIC interrupt space.  The DT interrupt
> specifier number space can more than handle the features of the GIC in
> a clear and concise manor.  So, here's my counter proposal for a GIC
> bindings (using Rob's text as the starting point):
> 
> ----
> 
> * ARM Generic Interrupt Controller
> 
> ARM SMP cores are often associated with a GIC, providing per processor
> interrupts (PPI), shared processor interrupts (SPI) and software
> generated interrupts (SGI).
> 
> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
> Secondary GICs are cascaded into the upward interrupt controller and do not
> have PPIs or SGIs.
> 
> Main node required properties:
> 
> - compatible : should be one of:
>        "arm,cortex-a9-gic"
>        "arm,arm11mp-gic"
> - interrupt-controller : Identifies the node as an interrupt controller
> - #interrupt-cells : Specifies the number of cells needed to encode an
>   interrupt source.  The type shall be a <u32> and the value shall be 3.
> 
>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
> interrupts.
>   The 2nd cell contains the interrupt number for the interrupt type.
> SPI interrupts are in the range [0-987].  PPI interrupts are in the
> range [0-15].
>   The 3rd cell is the flags, encoded as follows:
>         bits[3:0] trigger type and level flags.
>                     1 = low-to-high edge triggered
>                     2 = high-to-low edge triggered
>                     4 = active high level-sensitive
>                     8 = active low level-sensitive
>         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
> indicated the interrupt is wired to that CPU.  Only valid for PPI
> interrupts.
> 
How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
drop the first cell.

> (Alternately, if there is no need for a CPU mask because PPI
> interrupts will never be wired to more than one CPU, then it would be
> better to encode the CPU number into the second cell with the SPI
> number).
You meant PPI number, right?                                    ^^^

The common case at least on the A9 is a PPI is routed to all cores. QC
is different though. This was discussed previously. Basically, anything
is possible here, so the mask is needed for sure.

Overall I'm fine with this and just happy to have some conclusion. I
will send out an updated series if there are no further comments.

Rob

> 
> - reg : Specifies base physical address(s) and size of the GIC registers. The
>   first 2 values are the GIC distributor register base and size. The 2nd 2
>   values are the GIC cpu interface register base and size.
> 
> Optional
> - interrupts   : Interrupt source of the parent interrupt controller. Only
>   present on secondary GICs.
> 
> Example:
>        intc: interrupt-controller at fff11000 {
>                compatible = "arm,cortex-a9-gic";
>                #interrupt-cells = <3>;
>                #address-cells = <1>;
>                interrupt-controller;
>                reg = <0xfff11000 0x1000>,
>                      <0xfff10100 0x100>;
>        };

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 3:53 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>>        "arm,cortex-a9-gic"
>>        "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>   interrupt source.  The type shall be a <u32> and the value shall be 3.
>>
>>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>>   The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987].  PPI interrupts are in the
>> range [0-15].
>>   The 3rd cell is the flags, encoded as follows:
>>         bits[3:0] trigger type and level flags.
>>                     1 = low-to-high edge triggered
>>                     2 = high-to-low edge triggered
>>                     4 = active high level-sensitive
>>                     8 = active low level-sensitive
>>         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
>> indicated the interrupt is wired to that CPU.  Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.

Cells are cheap, and it is better to be explicit.  It is certainly
easier to extend in the future too if the type cell is used.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 3:53 PM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>>        "arm,cortex-a9-gic"
>>        "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>   interrupt source.  The type shall be a <u32> and the value shall be 3.
>>
>>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>>   The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987].  PPI interrupts are in the
>> range [0-15].
>>   The 3rd cell is the flags, encoded as follows:
>>         bits[3:0] trigger type and level flags.
>>                     1 = low-to-high edge triggered
>>                     2 = high-to-low edge triggered
>>                     4 = active high level-sensitive
>>                     8 = active low level-sensitive
>>         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
>> indicated the interrupt is wired to that CPU.  Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.

Cells are cheap, and it is better to be explicit.  It is certainly
easier to extend in the future too if the type cell is used.

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 3:53 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>> ? ? ? ?"arm,cortex-a9-gic"
>> ? ? ? ?"arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>> ? interrupt source. ?The type shall be a <u32> and the value shall be 3.
>>
>> ? The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>> ? The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987]. ?PPI interrupts are in the
>> range [0-15].
>> ? The 3rd cell is the flags, encoded as follows:
>> ? ? ? ? bits[3:0] trigger type and level flags.
>> ? ? ? ? ? ? ? ? ? ? 1 = low-to-high edge triggered
>> ? ? ? ? ? ? ? ? ? ? 2 = high-to-low edge triggered
>> ? ? ? ? ? ? ? ? ? ? 4 = active high level-sensitive
>> ? ? ? ? ? ? ? ? ? ? 8 = active low level-sensitive
>> ? ? ? ? bits[15:8] PPI interrupt cpu mask. ?Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC. ?A bit set to '1'
>> indicated the interrupt is wired to that CPU. ?Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.

Cells are cheap, and it is better to be explicit.  It is certainly
easier to extend in the future too if the type cell is used.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 04:53:39PM -0500, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
> > (Alternately, if there is no need for a CPU mask because PPI
> > interrupts will never be wired to more than one CPU, then it would be
> > better to encode the CPU number into the second cell with the SPI
> > number).
> You meant PPI number, right?                                    ^^^

Yes, I meant PPI number.  I keep transposing the two; I don't know why.

> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.

Okay.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 04:53:39PM -0500, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
> > (Alternately, if there is no need for a CPU mask because PPI
> > interrupts will never be wired to more than one CPU, then it would be
> > better to encode the CPU number into the second cell with the SPI
> > number).
> You meant PPI number, right?                                    ^^^

Yes, I meant PPI number.  I keep transposing the two; I don't know why.

> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.

Okay.

g.

[PATCH 5/5] ARM: gic: add OF based initialization

[Grant Likely]

On Mon, Sep 19, 2011 at 04:53:39PM -0500, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
> > (Alternately, if there is no need for a CPU mask because PPI
> > interrupts will never be wired to more than one CPU, then it would be
> > better to encode the CPU number into the second cell with the SPI
> > number).
> You meant PPI number, right?                                    ^^^

Yes, I meant PPI number.  I keep transposing the two; I don't know why.

> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.

Okay.

g.

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 11:53 PM, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring<robherring2@gmail.com>  wrote:
>>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>>> I was headed down the path of implementing the 2nd option above,
>>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>>> stay at 16?
>>>>
>>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>>> to the CortexA9 MP core TRM [1], you can see that the PPI# ->  ID#
>>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>>> processor has its own private timers that can generate interrupts,
>>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>>> its own watchdog timers that can generate interrupts, using ID30.
>>>>
>>>> So in that case, it can makes sense to use the ID. But it is
>>>> interesting to note that the PPI is identified with a 0 based index
>>>> number.
>>>>
>>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>>> for the timer interrupt. The first would match 0 based SPI convention.
>>> The last 2 would both match the documentation. We could never use 2 as
>>> this will for sure be different and the GIC code will have no way to
>>> know how to do the translation to ID. The only sane choice is using the
>>> ID as you say.
>>>
>>> But you can't have it both ways. It does not make sense to use the ID
>>> for some interrupts and a different scheme for others.
>>
>> Hmmm, it seems to me that some orthogonal issues are getting
>> conflated.  Specifically, the binding vs. what the GIC driver using
>> internally.  For my own understanding, let me see if I can summarize
>> and clarify the problem.
>>
>> Each GIC IRQ is represented in 5 different ways:
>> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
>> 2) The DT binding to represent the connection.
>> 3) The Interrupt ID as specified by the GIC architecture reference[1]
>> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
>> 4) The internal HWIRQ representation used by the GIC driver
>> 5) The Linux VIRQ number that #4 maps to.
>>
>> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
>>
>> Some thoughts:
>> - Generally the DT binding (#2) should reflect the HW view of the
>> system (#1) since that is the number most likely to be represented in
>> hardware manuals.  The interrupt ID is an internal detail of the GIC,
>> and isn't really exposed in the block diagram of the hardware.
>> - Presumably it is preferable for the GIC to directly use the
>> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
>> efficient from an interrupt handling perspective, and indeed this is
>> currently what the GIC driver does.
>> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
>> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
>> - Though not necessarily as trivial, the mapping between Linux VIRQ
>> and HWIRQ is not fixed, and when migrating to DT it should be assumed
>> to be assigned at runtime.  Perhaps not so important for a core IRQ
>> controller like the GIC (as opposed to an i2c irq expander), but
>> assuming an fixed offset still should be avoided.  We may still force
>> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
>> necessary and the driver still needs to support remapping for a
>> secondary GIC.
>
> The irq base is dynamic in my series, but is typically still GIC ID =
> VIRQ for a primary GIC for now. A platform can adjust this with
> irq_alloc_descs if necessary (but recommended not to of course).
>
>>
>> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
>> binding should reflect the hardware connections, not the values used
>> by software for decoding IRQs.  Also, I see absolutely no need to use
>> separate nodes for each GIC interrupt space.  The DT interrupt
>> specifier number space can more than handle the features of the GIC in
>> a clear and concise manor.  So, here's my counter proposal for a GIC
>> bindings (using Rob's text as the starting point):
>>
>> ----
>>
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>>         "arm,cortex-a9-gic"
>>         "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>    interrupt source.  The type shall be a<u32>  and the value shall be 3.
>>
>>    The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>>    The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987].  PPI interrupts are in the
>> range [0-15].
>>    The 3rd cell is the flags, encoded as follows:
>>          bits[3:0] trigger type and level flags.
>>                      1 = low-to-high edge triggered
>>                      2 = high-to-low edge triggered
>>                      4 = active high level-sensitive
>>                      8 = active low level-sensitive
>>          bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
>> indicated the interrupt is wired to that CPU.  Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.
>
>> (Alternately, if there is no need for a CPU mask because PPI
>> interrupts will never be wired to more than one CPU, then it would be
>> better to encode the CPU number into the second cell with the SPI
>> number).
> You meant PPI number, right?                                    ^^^
>
> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.
>
> Overall I'm fine with this and just happy to have some conclusion. I
> will send out an updated series if there are no further comments.

I'm OK with that proposal too. That solve all the concerns I had.

Thanks for the good discussion,
Benoit

Re: [PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 11:53 PM, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring<robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>  wrote:
>>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>>> I was headed down the path of implementing the 2nd option above,
>>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>>> stay at 16?
>>>>
>>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>>> to the CortexA9 MP core TRM [1], you can see that the PPI# ->  ID#
>>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>>> processor has its own private timers that can generate interrupts,
>>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>>> its own watchdog timers that can generate interrupts, using ID30.
>>>>
>>>> So in that case, it can makes sense to use the ID. But it is
>>>> interesting to note that the PPI is identified with a 0 based index
>>>> number.
>>>>
>>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>>> for the timer interrupt. The first would match 0 based SPI convention.
>>> The last 2 would both match the documentation. We could never use 2 as
>>> this will for sure be different and the GIC code will have no way to
>>> know how to do the translation to ID. The only sane choice is using the
>>> ID as you say.
>>>
>>> But you can't have it both ways. It does not make sense to use the ID
>>> for some interrupts and a different scheme for others.
>>
>> Hmmm, it seems to me that some orthogonal issues are getting
>> conflated.  Specifically, the binding vs. what the GIC driver using
>> internally.  For my own understanding, let me see if I can summarize
>> and clarify the problem.
>>
>> Each GIC IRQ is represented in 5 different ways:
>> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
>> 2) The DT binding to represent the connection.
>> 3) The Interrupt ID as specified by the GIC architecture reference[1]
>> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
>> 4) The internal HWIRQ representation used by the GIC driver
>> 5) The Linux VIRQ number that #4 maps to.
>>
>> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
>>
>> Some thoughts:
>> - Generally the DT binding (#2) should reflect the HW view of the
>> system (#1) since that is the number most likely to be represented in
>> hardware manuals.  The interrupt ID is an internal detail of the GIC,
>> and isn't really exposed in the block diagram of the hardware.
>> - Presumably it is preferable for the GIC to directly use the
>> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
>> efficient from an interrupt handling perspective, and indeed this is
>> currently what the GIC driver does.
>> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
>> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
>> - Though not necessarily as trivial, the mapping between Linux VIRQ
>> and HWIRQ is not fixed, and when migrating to DT it should be assumed
>> to be assigned at runtime.  Perhaps not so important for a core IRQ
>> controller like the GIC (as opposed to an i2c irq expander), but
>> assuming an fixed offset still should be avoided.  We may still force
>> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
>> necessary and the driver still needs to support remapping for a
>> secondary GIC.
>
> The irq base is dynamic in my series, but is typically still GIC ID =
> VIRQ for a primary GIC for now. A platform can adjust this with
> irq_alloc_descs if necessary (but recommended not to of course).
>
>>
>> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
>> binding should reflect the hardware connections, not the values used
>> by software for decoding IRQs.  Also, I see absolutely no need to use
>> separate nodes for each GIC interrupt space.  The DT interrupt
>> specifier number space can more than handle the features of the GIC in
>> a clear and concise manor.  So, here's my counter proposal for a GIC
>> bindings (using Rob's text as the starting point):
>>
>> ----
>>
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>>         "arm,cortex-a9-gic"
>>         "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>    interrupt source.  The type shall be a<u32>  and the value shall be 3.
>>
>>    The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>>    The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987].  PPI interrupts are in the
>> range [0-15].
>>    The 3rd cell is the flags, encoded as follows:
>>          bits[3:0] trigger type and level flags.
>>                      1 = low-to-high edge triggered
>>                      2 = high-to-low edge triggered
>>                      4 = active high level-sensitive
>>                      8 = active low level-sensitive
>>          bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
>> indicated the interrupt is wired to that CPU.  Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.
>
>> (Alternately, if there is no need for a CPU mask because PPI
>> interrupts will never be wired to more than one CPU, then it would be
>> better to encode the CPU number into the second cell with the SPI
>> number).
> You meant PPI number, right?                                    ^^^
>
> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.
>
> Overall I'm fine with this and just happy to have some conclusion. I
> will send out an updated series if there are no further comments.

I'm OK with that proposal too. That solve all the concerns I had.

Thanks for the good discussion,
Benoit

[PATCH 5/5] ARM: gic: add OF based initialization

[Cousson, Benoit]

On 9/19/2011 11:53 PM, Rob Herring wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> On Mon, Sep 19, 2011 at 7:48 AM, Rob Herring<robherring2@gmail.com>  wrote:
>>> On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
>>>> On 9/18/2011 11:23 PM, Rob Herring wrote:
>>>>> I was headed down the path of implementing the 2nd option above,
>>>>> but had a dilemma. What would be the numbering base for PPIs in
>>>>> this case? Should it be 0 in the DT as proposed for SPIs or does it
>>>>> stay at 16?
>>>>
>>>> Both SGI and PPI are internal to the CortexA9 MP core, and referring
>>>> to the CortexA9 MP core TRM [1], you can see that the PPI# ->  ID#
>>>> mapping is already documented: - Private timer, PPI(2) Each Cortex-A9
>>>> processor has its own private timers that can generate interrupts,
>>>> using ID29. - Watchdog timers, PPI(3) Each Cortex-A9 processor has
>>>> its own watchdog timers that can generate interrupts, using ID30.
>>>>
>>>> So in that case, it can makes sense to use the ID. But it is
>>>> interesting to note that the PPI is identified with a 0 based index
>>>> number.
>>>>
>>> It's even worse than I thought: we could use 13 (ID16 == PPI0), 29 or 2
>>> for the timer interrupt. The first would match 0 based SPI convention.
>>> The last 2 would both match the documentation. We could never use 2 as
>>> this will for sure be different and the GIC code will have no way to
>>> know how to do the translation to ID. The only sane choice is using the
>>> ID as you say.
>>>
>>> But you can't have it both ways. It does not make sense to use the ID
>>> for some interrupts and a different scheme for others.
>>
>> Hmmm, it seems to me that some orthogonal issues are getting
>> conflated.  Specifically, the binding vs. what the GIC driver using
>> internally.  For my own understanding, let me see if I can summarize
>> and clarify the problem.
>>
>> Each GIC IRQ is represented in 5 different ways:
>> 1) the hardware documentation (PPI[0-15] or SPI[988] input pin)
>> 2) The DT binding to represent the connection.
>> 3) The Interrupt ID as specified by the GIC architecture reference[1]
>> (SGI:[0-15], PPI:[16-31], SPI:[32-1019], special:[1020-1023])
>> 4) The internal HWIRQ representation used by the GIC driver
>> 5) The Linux VIRQ number that #4 maps to.
>>
>> [1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0048b/BCGBFHCH.html
>>
>> Some thoughts:
>> - Generally the DT binding (#2) should reflect the HW view of the
>> system (#1) since that is the number most likely to be represented in
>> hardware manuals.  The interrupt ID is an internal detail of the GIC,
>> and isn't really exposed in the block diagram of the hardware.
>> - Presumably it is preferable for the GIC to directly use the
>> Interrupt ID (#3) as the HWIRQ number (#4) because it is the most
>> efficient from an interrupt handling perspective, and indeed this is
>> currently what the GIC driver does.
>> - Translation between the DT binding (#2) and the Interrupt ID / HWIRQ
>> (#3/#4) is trivial, and easily managed by the GIC's irq_domain.
>> - Though not necessarily as trivial, the mapping between Linux VIRQ
>> and HWIRQ is not fixed, and when migrating to DT it should be assumed
>> to be assigned at runtime.  Perhaps not so important for a core IRQ
>> controller like the GIC (as opposed to an i2c irq expander), but
>> assuming an fixed offset still should be avoided.  We may still force
>> a SPI0->VIRQ32 on the root GIC as an optimization, but it is not
>> necessary and the driver still needs to support remapping for a
>> secondary GIC.
>
> The irq base is dynamic in my series, but is typically still GIC ID =
> VIRQ for a primary GIC for now. A platform can adjust this with
> irq_alloc_descs if necessary (but recommended not to of course).
>
>>
>> So, for the GIC DT binding, I'm inclined to agree with Benoit that the
>> binding should reflect the hardware connections, not the values used
>> by software for decoding IRQs.  Also, I see absolutely no need to use
>> separate nodes for each GIC interrupt space.  The DT interrupt
>> specifier number space can more than handle the features of the GIC in
>> a clear and concise manor.  So, here's my counter proposal for a GIC
>> bindings (using Rob's text as the starting point):
>>
>> ----
>>
>> * ARM Generic Interrupt Controller
>>
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>>
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>>
>> Main node required properties:
>>
>> - compatible : should be one of:
>>         "arm,cortex-a9-gic"
>>         "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>    interrupt source.  The type shall be a<u32>  and the value shall be 3.
>>
>>    The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>>    The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987].  PPI interrupts are in the
>> range [0-15].
>>    The 3rd cell is the flags, encoded as follows:
>>          bits[3:0] trigger type and level flags.
>>                      1 = low-to-high edge triggered
>>                      2 = high-to-low edge triggered
>>                      4 = active high level-sensitive
>>                      8 = active low level-sensitive
>>          bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
>> indicated the interrupt is wired to that CPU.  Only valid for PPI
>> interrupts.
>>
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.
>
>> (Alternately, if there is no need for a CPU mask because PPI
>> interrupts will never be wired to more than one CPU, then it would be
>> better to encode the CPU number into the second cell with the SPI
>> number).
> You meant PPI number, right?                                    ^^^
>
> The common case at least on the A9 is a PPI is routed to all cores. QC
> is different though. This was discussed previously. Basically, anything
> is possible here, so the mask is needed for sure.
>
> Overall I'm fine with this and just happy to have some conclusion. I
> will send out an updated series if there are no further comments.

I'm OK with that proposal too. That solve all the concerns I had.

Thanks for the good discussion,
Benoit