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 <[email protected]>
---
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
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 <[email protected]>
---
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
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 <[email protected]>
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
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 <[email protected]>
> ---
> 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 <[email protected]>
Tested-by: Thierry Reding <[email protected]>
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
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<[email protected]>
> Tested-by: Thierry Reding<[email protected]>
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
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
* 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
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
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 <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
---
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
Commit-ID: ece3234a77ebcd5bbeea6b829c9798328d290cae
Gitweb: http://git.kernel.org/tip/ece3234a77ebcd5bbeea6b829c9798328d290cae
Author: Sebastian Andrzej Siewior <[email protected]>
AuthorDate: Mon, 13 Aug 2012 22:23:33 +0200
Committer: Thomas Gleixner <[email protected]>
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 <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Cc: Grant Likely <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Thomas Gleixner <[email protected]>
---
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;
}
}
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
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
* 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