[PATCH] x86/ioapic: Fix fallout from IRQ domain conversion

[PATCH] x86/ioapic: Fix fallout from IRQ domain conversion

[Thierry Reding]

When I/O APIC support was converted to the generic IRQ domain code,
various things were broken. First, the number of interrupts required for
an I/O APIC can be dynamically obtained from the mp_ioapic_gsi structure
instead of hardcoded to 32. Furthermore, the legacy IRQ domain requires
the irq_domain_ops.map() function to be implemented, which it currently
isn't. This function can be empty because all the programming is done in
io_apic_setup_irq_pin_once().

Another issue is that the number of interrupts reserved is currently
determined by the value of the NR_IRQS_LEGACY macro (16). However the
legacy IRQ domain mapping needs at least the number of interrupts
provided by the I/O APIC. If an I/O APIC has been registered that number
is dynamically computed and used instead of NR_IRQS_LEGACY.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 arch/x86/kernel/apic/io_apic.c |  5 +++++
 arch/x86/kernel/devicetree.c   | 13 +++++++++++--
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 5f0ff59..2674ab0 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3465,6 +3465,7 @@ int get_nr_irqs_gsi(void)
 
 int __init arch_probe_nr_irqs(void)
 {
+	struct mp_ioapic_gsi *gsi_cfg;
 	int nr;
 
 	if (nr_irqs > (NR_VECTORS * nr_cpu_ids))
@@ -3480,6 +3481,10 @@ int __init arch_probe_nr_irqs(void)
 	if (nr < nr_irqs)
 		nr_irqs = nr;
 
+	gsi_cfg = mp_ioapic_gsi_routing(0);
+	if (gsi_cfg)
+		return gsi_cfg->gsi_end - gsi_cfg->gsi_base;
+
 	return NR_IRQS_LEGACY;
 }
 
diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 3ae2ced..ecc405a 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -338,8 +338,15 @@ static int ioapic_xlate(struct irq_domain *domain,
 	return 0;
 }
 
+static int ioapic_map(struct irq_domain *domain, unsigned int virq,
+		      irq_hw_number_t hw)
+{
+	return 0;
+}
+
 const struct irq_domain_ops ioapic_irq_domain_ops = {
 	.xlate = ioapic_xlate,
+	.map = ioapic_map,
 };
 
 static void __init ioapic_add_ofnode(struct device_node *np)
@@ -358,11 +365,13 @@ static void __init ioapic_add_ofnode(struct device_node *np)
 		if (r.start == mpc_ioapic_addr(i)) {
 			struct irq_domain *id;
 			struct mp_ioapic_gsi *gsi_cfg;
+			unsigned int num;
 
 			gsi_cfg = mp_ioapic_gsi_routing(i);
+			num = gsi_cfg->gsi_end - gsi_cfg->gsi_base;
 
-			id = irq_domain_add_legacy(np, 32, gsi_cfg->gsi_base, 0,
-						   &ioapic_irq_domain_ops,
+			id = irq_domain_add_legacy(np, num, gsi_cfg->gsi_base,
+						   0, &ioapic_irq_domain_ops,
 						   (void*)i);
 			BUG_ON(!id);
 			return;
-- 
1.7.11.3

[PATCH] x86/dt: use linear irq domain for ioapic(s).

[Sebastian Andrzej Siewior]

The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq <-> line mapping directly into ioapic) but this would
require a different irq lookup in "do_IRQ()" and won't work with ACPI
without changes. So this is probably easiest for everyone.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
 arch/x86/kernel/devicetree.c |   52 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 43 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 3ae2ced..df225fc 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -342,6 +342,48 @@ const struct irq_domain_ops ioapic_irq_domain_ops = {
 	.xlate = ioapic_xlate,
 };
 
+static void dt_add_ioapic_domain(unsigned int ioapic_num,
+		struct device_node *np)
+{
+	struct irq_domain *id;
+	struct mp_ioapic_gsi *gsi_cfg;
+	int ret;
+	int num;
+
+	gsi_cfg = mp_ioapic_gsi_routing(ioapic_num);
+	num = gsi_cfg->gsi_end - gsi_cfg->gsi_base + 1;
+
+	id = irq_domain_add_linear(np, num,
+			&ioapic_irq_domain_ops,
+			(void *)ioapic_num);
+	BUG_ON(!id);
+	if (gsi_cfg->gsi_base == 0) {
+		/*
+		 * The first NR_IRQS_LEGACY irq descs are allocated in
+		 * early_irq_init() and need just a mapping. The
+		 * remaining irqs need both. All of them are preallocated
+		 * and assigned so we can keep the 1:1 mapping which the ioapic
+		 * is having.
+		 */
+		ret = irq_domain_associate_many(id, 0, 0, NR_IRQS_LEGACY);
+		if (ret)
+			pr_err("Error mapping legacy irqs: %d\n", ret);
+
+		if (num > NR_IRQS_LEGACY) {
+			ret = irq_create_strict_mappings(id, NR_IRQS_LEGACY,
+					NR_IRQS_LEGACY, num - NR_IRQS_LEGACY);
+			if (ret)
+				pr_err("Error creating mapping for the "
+						"remaining  irqs: %d\n", ret);
+		}
+		irq_set_default_host(id);
+	} else {
+		ret = irq_create_strict_mappings(id, gsi_cfg->gsi_base, 0, num);
+		if (ret)
+			pr_err("Error creating irq mapping: %d\n", ret);
+	}
+}
+
 static void __init ioapic_add_ofnode(struct device_node *np)
 {
 	struct resource r;
@@ -356,15 +398,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)
 
 	for (i = 0; i < nr_ioapics; i++) {
 		if (r.start == mpc_ioapic_addr(i)) {
-			struct irq_domain *id;
-			struct mp_ioapic_gsi *gsi_cfg;
-
-			gsi_cfg = mp_ioapic_gsi_routing(i);
-
-			id = irq_domain_add_legacy(np, 32, gsi_cfg->gsi_base, 0,
-						   &ioapic_irq_domain_ops,
-						   (void*)i);
-			BUG_ON(!id);
+			dt_add_ioapic_domain(i, np);
 			return;
 		}
 	}
-- 
1.7.10.4

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

On Mon, Aug 06, 2012 at 09:38:11AM +0200, Sebastian Andrzej Siewior wrote:
> The former conversion to irq_domain_add_legacy() did not fully work
> since we miss the irq decs for NR_IRQS_LEGACY+.
> Ideally we could use irq_domain_add_simple() or the no-map variant (and
> program the virq <-> line mapping directly into ioapic) but this would
> require a different irq lookup in "do_IRQ()" and won't work with ACPI
> without changes. So this is probably easiest for everyone.
> 
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

From a quick glance this looks much better than my patch. This depends
on a couple of patches in linux-next it seems, so I'll have to do some
rebasing before I can test. Still I think I should be able to get back
to you until the end of the week.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3943 bytes --]

On Mon, Aug 06, 2012 at 09:38:11AM +0200, Sebastian Andrzej Siewior wrote:
> The former conversion to irq_domain_add_legacy() did not fully work
> since we miss the irq decs for NR_IRQS_LEGACY+.
> Ideally we could use irq_domain_add_simple() or the no-map variant (and
> program the virq <-> line mapping directly into ioapic) but this would
> require a different irq lookup in "do_IRQ()" and won't work with ACPI
> without changes. So this is probably easiest for everyone.
> 
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> ---
>  arch/x86/kernel/devicetree.c |   52 ++++++++++++++++++++++++++++++++++--------
>  1 file changed, 43 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index 3ae2ced..df225fc 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -342,6 +342,48 @@ const struct irq_domain_ops ioapic_irq_domain_ops = {
>  	.xlate = ioapic_xlate,
>  };
>  
> +static void dt_add_ioapic_domain(unsigned int ioapic_num,
> +		struct device_node *np)
> +{
> +	struct irq_domain *id;
> +	struct mp_ioapic_gsi *gsi_cfg;
> +	int ret;
> +	int num;
> +
> +	gsi_cfg = mp_ioapic_gsi_routing(ioapic_num);
> +	num = gsi_cfg->gsi_end - gsi_cfg->gsi_base + 1;
> +
> +	id = irq_domain_add_linear(np, num,
> +			&ioapic_irq_domain_ops,
> +			(void *)ioapic_num);

This fits on two lines instead of three.

> +	BUG_ON(!id);
> +	if (gsi_cfg->gsi_base == 0) {
> +		/*
> +		 * The first NR_IRQS_LEGACY irq descs are allocated in
> +		 * early_irq_init() and need just a mapping. The
> +		 * remaining irqs need both. All of them are preallocated
> +		 * and assigned so we can keep the 1:1 mapping which the ioapic
> +		 * is having.
> +		 */
> +		ret = irq_domain_associate_many(id, 0, 0, NR_IRQS_LEGACY);
> +		if (ret)
> +			pr_err("Error mapping legacy irqs: %d\n", ret);
> +
> +		if (num > NR_IRQS_LEGACY) {
> +			ret = irq_create_strict_mappings(id, NR_IRQS_LEGACY,
> +					NR_IRQS_LEGACY, num - NR_IRQS_LEGACY);
> +			if (ret)
> +				pr_err("Error creating mapping for the "
> +						"remaining  irqs: %d\n", ret);

There's an extra space between "remaining" and "irqs". Also other places
use the spelling IRQ and IRQs respectively in strings, so it may be nice
to stay consistent.

> +		}
> +		irq_set_default_host(id);
> +	} else {
> +		ret = irq_create_strict_mappings(id, gsi_cfg->gsi_base, 0, num);
> +		if (ret)
> +			pr_err("Error creating irq mapping: %d\n", ret);
> +	}
> +}
> +
>  static void __init ioapic_add_ofnode(struct device_node *np)
>  {
>  	struct resource r;
> @@ -356,15 +398,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)
>  
>  	for (i = 0; i < nr_ioapics; i++) {
>  		if (r.start == mpc_ioapic_addr(i)) {
> -			struct irq_domain *id;
> -			struct mp_ioapic_gsi *gsi_cfg;
> -
> -			gsi_cfg = mp_ioapic_gsi_routing(i);
> -
> -			id = irq_domain_add_legacy(np, 32, gsi_cfg->gsi_base, 0,
> -						   &ioapic_irq_domain_ops,
> -						   (void*)i);
> -			BUG_ON(!id);
> +			dt_add_ioapic_domain(i, np);
>  			return;
>  		}
>  	}

Besides the above nitpicks:

Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>

On another note, I saw that you've used the "intel,ce4100" prefix in
various places and I wonder if it would be useful to replace them with
something more generic like "intel,hpet", "intel,lapic" and
"intel,ioapic" respectively. The hardware that I use is based on an Atom
N450 and works with the current code, so it really isn't ce4100-
specific.

Given that this is x86/devicetree only and fixes things that didn't work
before, can it go into 3.6? Backporting to stable is probably not worth
it because it depends on a number of other IRQ domain patches that are
only available in 3.6.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Sebastian Andrzej Siewior]

On 08/08/2012 12:46 PM, Thierry Reding wrote:
>> +	id = irq_domain_add_linear(np, num,
>> +			&ioapic_irq_domain_ops,
>> +			(void *)ioapic_num);
>
> This fits on two lines instead of three.

k

>> +				pr_err("Error creating mapping for the "
>> +						"remaining  irqs: %d\n", ret);
>
> There's an extra space between "remaining" and "irqs". Also other places
> use the spelling IRQ and IRQs respectively in strings, so it may be nice
> to stay consistent.

I see.

> Besides the above nitpicks:
>
> Reviewed-by: Thierry Reding<thierry.reding@avionic-design.de>
> Tested-by: Thierry Reding<thierry.reding@avionic-design.de>

Thanks for testing.

> On another note, I saw that you've used the "intel,ce4100" prefix in
> various places and I wonder if it would be useful to replace them with
> something more generic like "intel,hpet", "intel,lapic" and
> "intel,ioapic" respectively. The hardware that I use is based on an Atom
> N450 and works with the current code, so it really isn't ce4100-
> specific.

No. You do have a compatible entry. It first appeared on the ce4100
CPU. If it happens to also work on the n450 then it seems to be
compatible with that one. "This" is documented somewhere…
Usually you add 'compatible = "your cpu", "generic binding"' in case
you need a fixup / errata whatever for "your cpu". Even if you compare
all hpets from Intel there is the one or other difference / errata.

> Thierry

Sebastian

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

On Wed, Aug 08, 2012 at 01:51:36PM +0200, Sebastian Andrzej Siewior wrote:
> On 08/08/2012 12:46 PM, Thierry Reding wrote:
> >On another note, I saw that you've used the "intel,ce4100" prefix in
> >various places and I wonder if it would be useful to replace them with
> >something more generic like "intel,hpet", "intel,lapic" and
> >"intel,ioapic" respectively. The hardware that I use is based on an Atom
> >N450 and works with the current code, so it really isn't ce4100-
> >specific.
> 
> No. You do have a compatible entry. It first appeared on the ce4100
> CPU. If it happens to also work on the n450 then it seems to be
> compatible with that one. "This" is documented somewhere…
> Usually you add 'compatible = "your cpu", "generic binding"' in case
> you need a fixup / errata whatever for "your cpu". Even if you compare
> all hpets from Intel there is the one or other difference / errata.

Exactly, but "ce4100-hpet" isn't very generic. What I'm saying is that
the last entry in the compatible list should be something generic, like
"intel,hpet", which can be overridden by putting a more specific entry
in front. I'd expect the ce4100 HPET to use something like this:

	compatible = "intel,ce4100-hpet", "intel,hpet";

On N450 this could for instance be:

	compatible = "intel,n450-hpet", "intel,hpet";

With that in place, the driver code can match on "intel,hpet" to catch
all implementations and use the more specific entries if quirks are
required for the specific hardware.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Sebastian Andrzej Siewior]

* Thierry Reding | 2012-08-08 14:07:37 [+0200]:

>With that in place, the driver code can match on "intel,hpet" to catch
>all implementations and use the more specific entries if quirks are
>required for the specific hardware.

from http://lkml.org/lkml/2011/2/16/350:

|"intel,ioapic" is probably too generic and can be dropped.  Newer
|devices can claim compatibility with "intel,ioapic-ce4100" if they are
|indeed compatible so that device drivers don't need to be modified.
|It is better to anchor compatible values to real implementations that
|try to come up with 'generic' or wildcard strings.  Ditto through the
|rest of the file.

>Thierry

Sebastian

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

On Sat, Aug 11, 2012 at 07:26:38PM +0200, Sebastian Andrzej Siewior wrote:
> * Thierry Reding | 2012-08-08 14:07:37 [+0200]:
> 
> >With that in place, the driver code can match on "intel,hpet" to catch
> >all implementations and use the more specific entries if quirks are
> >required for the specific hardware.
> 
> from http://lkml.org/lkml/2011/2/16/350:
> 
> |"intel,ioapic" is probably too generic and can be dropped.  Newer
> |devices can claim compatibility with "intel,ioapic-ce4100" if they are
> |indeed compatible so that device drivers don't need to be modified.
> |It is better to anchor compatible values to real implementations that
> |try to come up with 'generic' or wildcard strings.  Ditto through the
> |rest of the file.

Oh well. I've seen just the opposite used on ARM, where you start from a
generic implementation and compatible value and use more specific
compatible values for device-specific quirks.

But okay, the hardware that I use seems to work fine anyway, so I'll
just leave it as-is.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

[PATCH v2] x86/dt: use linear irq domain for ioapic(s).

[Sebastian Andrzej Siewior]

The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.
Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq <-> line mapping directly into ioapic) but this would
require a different irq lookup in "do_IRQ()" and won't work with ACPI
without changes. So this is probably easiest for everyone.

Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
v1..v2: - added tested tag from Thierry
	- moved argument ioapic_irq_domain_ops of irq_domain_add_linear() one
	  line up
	- removed one extra space "remaining" and "irqs"
	- use IRQs and IRQ instead of irq and irqs in printks.
	  
 arch/x86/kernel/devicetree.c |   51 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 3ae2ced..8bd7a2e 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -342,6 +342,47 @@ const struct irq_domain_ops ioapic_irq_domain_ops = {
 	.xlate = ioapic_xlate,
 };
 
+static void dt_add_ioapic_domain(unsigned int ioapic_num,
+		struct device_node *np)
+{
+	struct irq_domain *id;
+	struct mp_ioapic_gsi *gsi_cfg;
+	int ret;
+	int num;
+
+	gsi_cfg = mp_ioapic_gsi_routing(ioapic_num);
+	num = gsi_cfg->gsi_end - gsi_cfg->gsi_base + 1;
+
+	id = irq_domain_add_linear(np, num, &ioapic_irq_domain_ops,
+			(void *)ioapic_num);
+	BUG_ON(!id);
+	if (gsi_cfg->gsi_base == 0) {
+		/*
+		 * The first NR_IRQS_LEGACY irq descs are allocated in
+		 * early_irq_init() and need just a mapping. The
+		 * remaining irqs need both. All of them are preallocated
+		 * and assigned so we can keep the 1:1 mapping which the ioapic
+		 * is having.
+		 */
+		ret = irq_domain_associate_many(id, 0, 0, NR_IRQS_LEGACY);
+		if (ret)
+			pr_err("Error mapping legacy IRQs: %d\n", ret);
+
+		if (num > NR_IRQS_LEGACY) {
+			ret = irq_create_strict_mappings(id, NR_IRQS_LEGACY,
+					NR_IRQS_LEGACY, num - NR_IRQS_LEGACY);
+			if (ret)
+				pr_err("Error creating mapping for the "
+						"remaining IRQs: %d\n", ret);
+		}
+		irq_set_default_host(id);
+	} else {
+		ret = irq_create_strict_mappings(id, gsi_cfg->gsi_base, 0, num);
+		if (ret)
+			pr_err("Error creating IRQ mapping: %d\n", ret);
+	}
+}
+
 static void __init ioapic_add_ofnode(struct device_node *np)
 {
 	struct resource r;
@@ -356,15 +397,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)
 
 	for (i = 0; i < nr_ioapics; i++) {
 		if (r.start == mpc_ioapic_addr(i)) {
-			struct irq_domain *id;
-			struct mp_ioapic_gsi *gsi_cfg;
-
-			gsi_cfg = mp_ioapic_gsi_routing(i);
-
-			id = irq_domain_add_legacy(np, 32, gsi_cfg->gsi_base, 0,
-						   &ioapic_irq_domain_ops,
-						   (void*)i);
-			BUG_ON(!id);
+			dt_add_ioapic_domain(i, np);
 			return;
 		}
 	}
-- 
1.7.10.4

[tip:x86/apic] x86: dt: Use linear irq domain for ioapic(s)

[tip-bot for Sebastian Andrzej Siewior]

Commit-ID:  ece3234a77ebcd5bbeea6b829c9798328d290cae
Gitweb:     http://git.kernel.org/tip/ece3234a77ebcd5bbeea6b829c9798328d290cae
Author:     Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
AuthorDate: Mon, 13 Aug 2012 22:23:33 +0200
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 21 Aug 2012 22:16:57 +0200

x86: dt: Use linear irq domain for ioapic(s)

The former conversion to irq_domain_add_legacy() did not fully work
since we miss the irq decs for NR_IRQS_LEGACY+.

Ideally we could use irq_domain_add_simple() or the no-map variant (and
program the virq <-> line mapping directly into ioapic) but this would
require a different irq lookup in "do_IRQ()" and won't work with ACPI
without changes. So this is probably easiest for everyone.

Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Link: http://lkml.kernel.org/r/20120813202304.GA3529@breakpoint.cc
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/devicetree.c |   51 ++++++++++++++++++++++++++++++++++-------
 1 files changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index 3ae2ced..b158152 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -342,6 +342,47 @@ const struct irq_domain_ops ioapic_irq_domain_ops = {
 	.xlate = ioapic_xlate,
 };
 
+static void dt_add_ioapic_domain(unsigned int ioapic_num,
+		struct device_node *np)
+{
+	struct irq_domain *id;
+	struct mp_ioapic_gsi *gsi_cfg;
+	int ret;
+	int num;
+
+	gsi_cfg = mp_ioapic_gsi_routing(ioapic_num);
+	num = gsi_cfg->gsi_end - gsi_cfg->gsi_base + 1;
+
+	id = irq_domain_add_linear(np, num, &ioapic_irq_domain_ops,
+			(void *)ioapic_num);
+	BUG_ON(!id);
+	if (gsi_cfg->gsi_base == 0) {
+		/*
+		 * The first NR_IRQS_LEGACY irq descs are allocated in
+		 * early_irq_init() and need just a mapping. The
+		 * remaining irqs need both. All of them are preallocated
+		 * and assigned so we can keep the 1:1 mapping which the ioapic
+		 * is having.
+		 */
+		ret = irq_domain_associate_many(id, 0, 0, NR_IRQS_LEGACY);
+		if (ret)
+			pr_err("Error mapping legacy IRQs: %d\n", ret);
+
+		if (num > NR_IRQS_LEGACY) {
+			ret = irq_create_strict_mappings(id, NR_IRQS_LEGACY,
+					NR_IRQS_LEGACY, num - NR_IRQS_LEGACY);
+			if (ret)
+				pr_err("Error creating mapping for the "
+						"remaining IRQs: %d\n", ret);
+		}
+		irq_set_default_host(id);
+	} else {
+		ret = irq_create_strict_mappings(id, gsi_cfg->gsi_base, 0, num);
+		if (ret)
+			pr_err("Error creating IRQ mapping: %d\n", ret);
+	}
+}
+
 static void __init ioapic_add_ofnode(struct device_node *np)
 {
 	struct resource r;
@@ -356,15 +397,7 @@ static void __init ioapic_add_ofnode(struct device_node *np)
 
 	for (i = 0; i < nr_ioapics; i++) {
 		if (r.start == mpc_ioapic_addr(i)) {
-			struct irq_domain *id;
-			struct mp_ioapic_gsi *gsi_cfg;
-
-			gsi_cfg = mp_ioapic_gsi_routing(i);
-
-			id = irq_domain_add_legacy(np, 32, gsi_cfg->gsi_base, 0,
-						   &ioapic_irq_domain_ops,
-						   (void*)i);
-			BUG_ON(!id);
+			dt_add_ioapic_domain(i, np);
 			return;
 		}
 	}

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Florian Fainelli]

Sebastian Andrzej Siewior <bigeasy <at> linutronix.de> writes:
> 
> No. You do have a compatible entry. It first appeared on the ce4100
> CPU. If it happens to also work on the n450 then it seems to be
> compatible with that one. "This" is documented somewhere…
> Usually you add 'compatible = "your cpu", "generic binding"' in case
> you need a fixup / errata whatever for "your cpu". Even if you compare
> all hpets from Intel there is the one or other difference / errata.

Can we make sure that his hits the future 3.6 stable releases? We had to merge
this back to your 3.6 kernel tree in order to have a functionnal CE4100 system.

Thank you!
--
Florian

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Florian Fainelli]

On Friday 19 October 2012 11:36:25  Fainelli wrote:
> Sebastian Andrzej Siewior <bigeasy <at> linutronix.de> writes:
> > 
> > No. You do have a compatible entry. It first appeared on the ce4100
> > CPU. If it happens to also work on the n450 then it seems to be
> > compatible with that one. "This" is documented somewhere…
> > Usually you add 'compatible = "your cpu", "generic binding"' in case
> > you need a fixup / errata whatever for "your cpu". Even if you compare
> > all hpets from Intel there is the one or other difference / errata.
> 
> Can we make sure that his hits the future 3.6 stable releases? We had to merge
> this back to your 3.6 kernel tree in order to have a functionnal CE4100 system.
> 
> Thank you!

Adding Adding Thomas, Ingo and Sebastian in CC.
--
Florian

Re: [PATCH] x86/dt: use linear irq domain for ioapic(s).

[Sebastian Andrzej Siewior]

* Florian Fainelli | 2012-10-19 15:40:29 [+0200]:

>On Friday 19 October 2012 11:36:25  Fainelli wrote:
>> Sebastian Andrzej Siewior <bigeasy <at> linutronix.de> writes:
>> > 
>> > No. You do have a compatible entry. It first appeared on the ce4100
>> > CPU. If it happens to also work on the n450 then it seems to be
>> > compatible with that one. "This" is documented somewhere???
>> > Usually you add 'compatible = "your cpu", "generic binding"' in case
>> > you need a fixup / errata whatever for "your cpu". Even if you compare
>> > all hpets from Intel there is the one or other difference / errata.
>> 
>> Can we make sure that his hits the future 3.6 stable releases? We had to merge
>> this back to your 3.6 kernel tree in order to have a functionnal CE4100 system.
>> 
>> Thank you!
>
>Adding Adding Thomas, Ingo and Sebastian in CC.

If someone needs it, yes. My understanding was that Thierry said we need
a few OF specific patches and this alone won't help. Care to backport
and test & post it?

>--
>Florian

Sebastian