with set_irq_chip/data... to take desc instead of irq Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- arch/x86/kernel/apic/io_apic.c | 4 +- include/linux/irq.h | 10 +++- include/linux/irqnr.h | 1 + kernel/irq/chip.c | 127 +++++++++++++++++++++++----------------- 4 files changed, 85 insertions(+), 57 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index f908af5..432bea1 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3302,7 +3302,7 @@ unsigned int create_irq_nr(unsigned int irq_want, int node) raw_spin_unlock_irqrestore(&vector_lock, flags); if (irq > 0) - dynamic_irq_init_keep_chip_data(irq); + dynamic_irq_init_keep_chip_data(irq_to_desc(irq)); return irq; } @@ -3328,7 +3328,7 @@ void destroy_irq(unsigned int irq) struct irq_desc *desc; struct irq_cfg *cfg; - dynamic_irq_cleanup_keep_chip_data(irq); + dynamic_irq_cleanup_keep_chip_data(irq_to_desc(irq)); free_irte(irq); raw_spin_lock_irqsave(&vector_lock, flags); diff --git a/include/linux/irq.h b/include/linux/irq.h index 36ea6ac..1f5d112 100644 --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -420,9 +420,9 @@ static inline int irq_has_action(unsigned int irq) /* Dynamic irq helper functions */ extern void dynamic_irq_init(unsigned int irq); -void dynamic_irq_init_keep_chip_data(unsigned int irq); +void dynamic_irq_init_keep_chip_data(struct irq_desc *desc); extern void dynamic_irq_cleanup(unsigned int irq); -void dynamic_irq_cleanup_keep_chip_data(unsigned int irq); +void dynamic_irq_cleanup_keep_chip_data(struct irq_desc *desc); /* Set/get chip/data for an IRQ: */ extern int set_irq_chip(unsigned int irq, struct irq_chip *chip); @@ -431,6 +431,12 @@ extern int set_irq_chip_data(unsigned int irq, void *data); extern int set_irq_type(unsigned int irq, unsigned int type); extern int set_irq_msi(unsigned int irq, struct msi_desc ...
so keep nr_irqs == NR_IRQS
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/kernel/apic/io_apic.c | 22 ----------------------
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index ce93428..b9c4749 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3921,28 +3921,6 @@ void __init probe_nr_irqs_gsi(void)
printk(KERN_DEBUG "nr_irqs_gsi: %d\n", nr_irqs_gsi);
}
-#ifdef CONFIG_SPARSE_IRQ
-int __init arch_probe_nr_irqs(void)
-{
- int nr;
-
- if (nr_irqs > (NR_VECTORS * nr_cpu_ids))
- nr_irqs = NR_VECTORS * nr_cpu_ids;
-
- nr = nr_irqs_gsi + 8 * nr_cpu_ids;
-#if defined(CONFIG_PCI_MSI) || defined(CONFIG_HT_IRQ)
- /*
- * for MSI and HT dyn irq
- */
- nr += nr_irqs_gsi * 16;
-#endif
- if (nr < nr_irqs)
- nr_irqs = nr;
-
- return 0;
-}
-#endif
-
static int __io_apic_set_pci_routing(struct device *dev, int irq,
struct io_apic_irq_attr *irq_attr)
{
--
1.6.4.2
--
Iranna D Ankad reported that IBM x3950 systems have boot problems
after this commit:
|
| commit b9c61b70075c87a8612624736faf4a2de5b1ed30
|
| x86/pci: update pirq_enable_irq() to setup io apic routing
|
ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2
ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38
ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74
As explained in the previous patch ("x86: Fix out of order gsi)
need to remap those gsis
This patch adds boot_ioapic_idx and gsi_to_irq/irq_to_gsi
So we could make sure for those kind of system will have
irq: 0 - 15 for legacy irq
irq: 16 after will be gsi + 16
-v13: move gsi_to_irq/irq_to_gsi to acpi/boot.c
Reported-by: Iranna D Ankad <iranna.ankad@in.ibm.com>
Bisected-by: Iranna D Ankad <iranna.ankad@in.ibm.com>
Tested-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: len.brown@intel.com
---
arch/x86/include/asm/io_apic.h | 2 +-
arch/x86/include/asm/mpspec.h | 14 ++++++++
arch/x86/kernel/acpi/boot.c | 64 +++++++++++++++++++++++++++++------
arch/x86/kernel/apic/io_apic.c | 72 +++++++++++++++++++++++++++++----------
drivers/pnp/pnpacpi/rsparser.c | 4 ++
5 files changed, 125 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 35832a0..c4683b9 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -158,7 +158,7 @@ extern int io_apic_get_redir_entries(int ioapic);
struct io_apic_irq_attr;
extern int io_apic_set_pci_routing(struct device *dev, int irq,
struct io_apic_irq_attr ...Please do not propagate that pointer.
*irq = setup_IO_APIC_irq_extra(gsi);
Also these changes have a total lack of comments. Why do we modify
Please make this static and provide a function to modify it from
probe_ioapic_i8259().
Also the variable name is horrible. What's the delta here ? It's an
Please make that:
Why is mp_register_gsi global ? It's only used in
Can we please do a cleanup of irq variables to use unsigned
Can we simply return mp_irqs[idx].srcbusirq here and get rid of the
boot_ioapic_idx is an apic id. Why is the variable name suggesting
How is this change related to this patch ? It looks more like an
independent fix.
Thanks,
tglx
--
yes. should adjust that function position. arch/x86/kernel/acpi/boot.c: plat_gsi = mp_register_gsi(dev, gsi, trigger, polarity); ok another patch. YH --
I have played with this a bit and I have a cleaner patchset that addresses this issue. I plan to sleep on it, and then go through it again before I send it. Thomas is the procedure for working on this stuff write clean patches and send them, and they will land in an x86 topic branch? Eric --
It appears there are a few systems in the wild that use acpi
interrupt source overrides to report a gsi > 16 is an isa irq.
This breaks all kinds of assumptions I figure any BIOS doing that
probably should be shot as that is very much not a conservative position.
That said acpi appears to allow this insanity and on the basis of being
liberal in what we accept we should try to do something reasonable, and
keep our notions of gsi, isa irq, and linux irq as straight as we can.
To that end this patchset slightly modifies the gsi to linux irq
mapping. Making it a 1 to 1 identity mapping except for the first 16
gsis. If those gsis are isa irqs (the typical and default acpi
configuration) they will be mapped into the first 16 irqs. If those
first 16 gsis are not isa irqs they will be given a linux irq number
just past the last gsi. Allowing us the chance to use them.
This patchset is my attempt to straighten out our understanding of which
kind of irq name is used where and the cleanups used to get there.
Thanks to Yinghai Lu <yinghai@kernel.org> for taking the first stab at
this and finding that there is a real world problem here. This patchset
is inspired by his work, but little of it remains the same.
This patchset lies in the weird world between the acpi and x86 and ia64.
Since most of the changes are x86 related I think it makes most sense
to go via the x86 tree.
Eric W. Biederman (14):
x86 acpi/irq: Introduce apci_isa_irq_to_gsi
x86 acpi/irq: Teach acpi_get_override_irq to take a gsi not an isa_irq
x86 acpi/irq: pci device dev->irq is an isa irq not a gsi
x86 acpi/irq: Fix acpi_sci_ioapic_setup so it has both bus_irq and gsi
x86 acpi/irq: Generalize mp_config_acpi_legacy_irqs
x86 ioapic: Only export mp_find_ioapic and mp_find_ioapic_pin in io_apic.h
x86 ioapic: Fix the types of gsi values
x86 ioapic: Teach mp_register_ioapic to compute a global gsi_end
x86 ioapic: In mpparse use mp_register_ioapic
...From: Eric W. Biederman <ebiederm@xmission.com>
Strictly speaking on x86 (where acpi is used) dev->irq must be
a dual i8259 irq input aka an isa irq. Therefore we should translate
that isa irq into a gsi before passing it to a function that
takes a gsi.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
drivers/acpi/pci_irq.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 843699e..703541d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -400,11 +400,13 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
* driver reported one, then use it. Exit in any case.
*/
if (gsi < 0) {
+ u32 dev_gsi;
dev_warn(&dev->dev, "PCI INT %c: no GSI", pin_name(pin));
/* Interrupt Line values above 0xF are forbidden */
- if (dev->irq > 0 && (dev->irq <= 0xF)) {
- printk(" - using IRQ %d\n", dev->irq);
- acpi_register_gsi(&dev->dev, dev->irq,
+ if (dev->irq > 0 && (dev->irq <= 0xF) &&
+ (acpi_isa_irq_to_gsi(dev->irq, &dev_gsi) == 0)) {
+ printk(" - using ISA IRQ %d\n", dev->irq);
+ acpi_register_gsi(&dev->dev, dev_gsi,
ACPI_LEVEL_SENSITIVE,
ACPI_ACTIVE_LOW);
return 0;
--
1.6.5.2.143.g8cc62
--
From: Eric W. Biederman <ebiederm@xmission.com>
This patches fixes the types of gsi_base and gsi_end values in
struct mp_ioapic_gsi, and the gsi parameter of mp_find_ioapic
and mp_find_ioapic_pin
A gsi is cannonically a u32, not an int.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 10 +++++-----
arch/x86/kernel/apic/io_apic.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 35832a0..feeaf0d 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -180,12 +180,12 @@ extern void ioapic_write_entry(int apic, int pin,
extern void setup_ioapic_ids_from_mpc(void);
struct mp_ioapic_gsi{
- int gsi_base;
- int gsi_end;
+ u32 gsi_base;
+ u32 gsi_end;
};
extern struct mp_ioapic_gsi mp_gsi_routing[];
-int mp_find_ioapic(int gsi);
-int mp_find_ioapic_pin(int ioapic, int gsi);
+int mp_find_ioapic(u32 gsi);
+int mp_find_ioapic_pin(int ioapic, u32 gsi);
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
extern void __init pre_init_apic_IRQ0(void);
@@ -197,7 +197,7 @@ static const int timer_through_8259 = 0;
static inline void ioapic_init_mappings(void) { }
static inline void ioapic_insert_resources(void) { }
static inline void probe_nr_irqs_gsi(void) { }
-static inline int mp_find_ioapic(int gsi) { return 0; }
+static inline int mp_find_ioapic(u32 gsi) { return 0; }
struct io_apic_irq_attr;
static inline int io_apic_set_pci_routing(struct device *dev, int irq,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 54ba1f7..32cea57 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -4234,7 +4234,7 @@ void __init ioapic_insert_resources(void)
}
}
-int mp_find_ioapic(int gsi)
+int mp_find_ioapic(u32 gsi)
{
int i = 0;
@@ -4249,7 +4249,7 @@ int mp_find_ioapic(int gsi)
return -1;
}
-int ...From: Eric W. Biederman <ebiederm@xmission.com>
Use the global gsi_end value now that all ioapics have
valid gsi numbers instead of a combination of acpi_probe_gsi
and walking all of the ioapics and couting their number of
entries by hand if acpi_probe_gsi gave us an answer we did
not like.
This fixes a small bug in probe_nr_irqs_gsi. Previously
acpi_probe_gsi unnecessarily added 1 to the maximum
gsi_end value. gsi_end is already one past the end of
the number of gsi's so the additional increment was
superfluous.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/mpspec.h | 6 ------
arch/x86/kernel/acpi/boot.c | 23 -----------------------
arch/x86/kernel/apic/io_apic.c | 17 +++--------------
3 files changed, 3 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 29994f0..c82868e 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -105,12 +105,6 @@ extern void mp_config_acpi_legacy_irqs(void);
struct device;
extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level,
int active_high_low);
-extern int acpi_probe_gsi(void);
-#else /* !CONFIG_ACPI: */
-static inline int acpi_probe_gsi(void)
-{
- return 0;
-}
#endif /* CONFIG_ACPI */
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 9c48e99..0e514a1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -875,29 +875,6 @@ static int __init acpi_parse_madt_lapic_entries(void)
extern int es7000_plat;
#endif
-int __init acpi_probe_gsi(void)
-{
- int idx;
- int gsi;
- int max_gsi = 0;
-
- if (acpi_disabled)
- return 0;
-
- if (!acpi_ioapic)
- return 0;
-
- max_gsi = 0;
- for (idx = 0; idx < nr_ioapics; idx++) {
- gsi = mp_gsi_routing[idx].gsi_end;
-
- if (gsi > max_gsi)
- max_gsi = gsi;
- }
-
- return max_gsi + 1;
-}
-
static ...On Mon, Mar 29, 2010 at 4:20 PM, Eric W. Biederman you may need +1 here --
As documented in my comment that extra +1 has every appearance of a bug. Nothing is at gsi_end. gsi_end is already at 1 past the last in use gsi. Therefore an extra +1 puts us two past the end for no apparent reason. Eric --
io_apic_get_redir_entries(), and io apic register readingout will return 23 if the total entries is 24.
[ 0.000000] ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: IOAPIC (id[0x09] address[0xfec02000] gsi_base[24])
[ 0.000000] IOAPIC[1]: apic_id 9, version 32, address 0xfec02000, GSI 24-47
[ 0.000000] ACPI: IOAPIC (id[0x0a] address[0xfec04000] gsi_base[48])
[ 0.000000] IOAPIC[2]: apic_id 10, version 32, address 0xfec04000, GSI 48-71
[ 0.000000] ACPI: IOAPIC (id[0x0b] address[0xfec08000] gsi_base[72])
[ 0.000000] IOAPIC[3]: apic_id 11, version 32, address 0xfec08000, GSI 72-95
[ 0.000000] ACPI: IOAPIC (id[0x0c] address[0xfec0c000] gsi_base[96])
[ 0.000000] IOAPIC[4]: apic_id 12, version 32, address 0xfec0c000, GSI 96-119
mp_gsi_routing[idx].gsi_end = gsi_base +
io_apic_get_redir_entries(idx);
printk(KERN_INFO "IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
"GSI %d-%d\n", idx, mp_ioapics[idx].apicid,
mp_ioapics[idx].apicver, mp_ioapics[idx].apicaddr,
mp_gsi_routing[idx].gsi_base, mp_gsi_routing[idx].gsi_end);
YH
--
Good catch. I don't know if I have ever seen a function with a name to function correspondence. Apparently sfi.c also got this wrong when it was written. and I missed the +1 in other places. I guess this calls for another patch way at the beginning of my series that fixes this brain damage. Eric --
From: Eric W. Biederman <ebiederm@xmission.com>
There are a number of cases where the current code makes the assumption
that isa irqs identity map to the first 16 acpi global system intereupts.
In most instances that assumption is correct as that is the required
behaviour in dual i8259 mode and the default behavior in ioapic mode.
However there are some systems out there that take advantage of acpis
interrupt remapping for the isa irqs to have a completely different
mapping of isa_irq to gsi.
Introduce acpi_isa_irq_to_gsi to perform this mapping explicitly in the
code that needs it. Initially this will be just the current assumed
identity mapping to ensure it's introduction does not cause regressions.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/ia64/kernel/acpi.c | 8 ++++++++
arch/x86/kernel/acpi/boot.c | 8 ++++++++
include/linux/acpi.h | 1 +
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index f1c9f70..16921bd 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -784,6 +784,14 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
return 0;
}
+int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
+{
+ if (isa_irq >= 16)
+ return -1;
+ *gsi = isa_irq;
+ return 0;
+}
+
/*
* ACPI based hotplug CPU support
*/
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0061ea2..f96060d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -457,6 +457,14 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
return 0;
}
+int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
+{
+ if (isa_irq >= 16)
+ return -1;
+ *gsi = isa_irq;
+ return 0;
+}
+
/*
* success: return IRQ number (>=0)
* failure: return < 0
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b926afe..7a937da 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -116,6 +116,7 @@ ...From: Eric W. Biederman <ebiederm@xmission.com>
Multiple declarations of the same function in different headers
is a pain to maintain.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/mpspec.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index d8bf23a..29994f0 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -106,10 +106,6 @@ struct device;
extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level,
int active_high_low);
extern int acpi_probe_gsi(void);
-#ifdef CONFIG_X86_IO_APIC
-extern int mp_find_ioapic(int gsi);
-extern int mp_find_ioapic_pin(int ioapic, int gsi);
-#endif
#else /* !CONFIG_ACPI: */
static inline int acpi_probe_gsi(void)
{
--
1.6.5.2.143.g8cc62
--
From: Eric W. Biederman <ebiederm@xmission.com>
Now that the generic irq layer is performing the exact same remapping as
io_apic_renumber_irq we can kill this weird es7000 specific function.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 1 -
arch/x86/kernel/acpi/boot.c | 5 -----
arch/x86/kernel/apic/es7000_32.c | 19 -------------------
arch/x86/kernel/apic/io_apic.c | 6 ------
4 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 37b0f2b..9da192a 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -159,7 +159,6 @@ struct io_apic_irq_attr;
extern int io_apic_set_pci_routing(struct device *dev, int irq,
struct io_apic_irq_attr *irq_attr);
void setup_IO_APIC_irq_extra(u32 gsi);
-extern int (*ioapic_renumber_irq)(int ioapic, int irq);
extern void ioapic_init_mappings(void);
extern void ioapic_insert_resources(void);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b372aba..a48dfa9 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1116,11 +1116,6 @@ int mp_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
ioapic_pin = mp_find_ioapic_pin(ioapic, gsi);
-#ifdef CONFIG_X86_32
- if (ioapic_renumber_irq)
- gsi = ioapic_renumber_irq(ioapic, gsi);
-#endif
-
if (ioapic_pin > MP_MAX_IOAPIC_PIN) {
printk(KERN_ERR "Invalid reference to IOAPIC pin "
"%d-%d\n", mp_ioapics[ioapic].apicid,
diff --git a/arch/x86/kernel/apic/es7000_32.c b/arch/x86/kernel/apic/es7000_32.c
index dd2b5f2..7a63d47 100644
--- a/arch/x86/kernel/apic/es7000_32.c
+++ b/arch/x86/kernel/apic/es7000_32.c
@@ -130,24 +130,6 @@ int es7000_plat;
static unsigned int base;
-static int
-es7000_rename_gsi(int ioapic, int gsi)
-{
- if (es7000_plat == ES7000_ZORRO)
- return gsi;
-
- if (!base) {
- int i;
- for ...From: Eric W. Biederman <ebiederm@xmission.com>
ACPI irq source overrides are allowed for the 16 isa irqs and are
allowed to map any gsi to any isa irq. A few motherboards have been
seen to take advantage of this and put the isa irqs on the 2nd or
3rd ioapic. This causes some problems, most notably the fact
that we can not use any gsi < 16.
To correct this move the gsis that are not isa irqs and have
a gsi number < 16 into the linux irq space just past gsi_end.
This is what the es7000 platform is doing today. Moving only the
low 16 gsis above the rest of the gsi's only penalizes weird
platforms, leaving sane acpi implementations with a 1-1 mapping
of gsis and irqs.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/acpi/boot.c | 57 +++++++++++++++++++++++++++++++++++++---
arch/x86/kernel/apic/io_apic.c | 8 ++++-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0e514a1..b372aba 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -92,6 +92,53 @@ static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC;
+/*
+ * ISA irqs by default are the first 16 gsis but can be
+ * any gsi as specified by an interrupt source override.
+ */
+static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
+ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
+};
+
+static unsigned int gsi_to_irq(unsigned int gsi)
+{
+ unsigned int irq = gsi + NR_IRQS_LEGACY;
+ unsigned int i;
+
+ for (i = 0; i < NR_IRQS_LEGACY; i++) {
+ if (isa_irq_to_gsi[i] == gsi) {
+ return i;
+ }
+ }
+
+ /* Provide an identity mapping of gsi == irq
+ * except on truly weird platforms that have
+ * non isa irqs in the first 16 gsis.
+ */
+ if (gsi >= NR_IRQS_LEGACY)
+ irq = gsi;
+ else
+ irq = gsi_end + gsi;
+
+ return irq;
+}
+
+static u32 irq_to_gsi(int irq)
+{
+ unsigned ...From: Eric W. Biederman <ebiederm@xmission.com>
Remove the assumption that there is not an override for isa irq 0.
Instead lookup the gsi and from that lookup the ioapic and pin of each
isa irq indivdually.
In general this should not have any behavioural affect but in
perverse cases this gets all of the details correct, instead of
doing something weird.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/acpi/boot.c | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1742888..9c48e99 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -960,8 +960,6 @@ void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger, u32 gsi)
void __init mp_config_acpi_legacy_irqs(void)
{
int i;
- int ioapic;
- unsigned int dstapic;
struct mpc_intsrc mp_irq;
#if defined (CONFIG_MCA) || defined (CONFIG_EISA)
@@ -982,19 +980,27 @@ void __init mp_config_acpi_legacy_irqs(void)
#endif
/*
- * Locate the IOAPIC that manages the ISA IRQs (0-15).
- */
- ioapic = mp_find_ioapic(0);
- if (ioapic < 0)
- return;
- dstapic = mp_ioapics[ioapic].apicid;
-
- /*
* Use the default configuration for the IRQs 0-15. Unless
* overridden by (MADT) interrupt source override entries.
*/
for (i = 0; i < 16; i++) {
+ int ioapic, pin;
+ unsigned int dstapic;
int idx;
+ u32 gsi;
+
+ /* Locate the gsi that irq i maps to. */
+ if (acpi_isa_irq_to_gsi(i, &gsi))
+ continue;
+
+ /*
+ * Locate the IOAPIC that manages the ISA IRQ.
+ */
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0)
+ continue;
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+ dstapic = mp_ioapics[ioapic].apicid;
for (idx = 0; idx < mp_irq_entries; idx++) {
struct mpc_intsrc *irq = mp_irqs + idx;
@@ -1004,7 +1010,7 @@ void __init mp_config_acpi_legacy_irqs(void)
break;
/* Do we already have a ...From: Eric W. Biederman <ebiederm@xmission.com>
Now that all ioapics have valid gsi_base values use this to
accellerate pin_2_irq. In the case of acpi this also ensures
that pin_2_irq will compute the same irq value for an ioapic
pin as acpi will.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/apic/io_apic.c | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 0515f26..996cf8f 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1018,7 +1018,7 @@ static inline int irq_trigger(int idx)
int (*ioapic_renumber_irq)(int ioapic, int irq);
static int pin_2_irq(int idx, int apic, int pin)
{
- int irq, i;
+ int irq;
int bus = mp_irqs[idx].srcbus;
/*
@@ -1030,18 +1030,13 @@ static int pin_2_irq(int idx, int apic, int pin)
if (test_bit(bus, mp_bus_not_pci)) {
irq = mp_irqs[idx].srcbusirq;
} else {
- /*
- * PCI IRQs are mapped in order
- */
- i = irq = 0;
- while (i < apic)
- irq += nr_ioapic_registers[i++];
- irq += pin;
+ u32 gsi = mp_gsi_routing[apic].gsi_base + pin;
/*
* For MPS mode, so far only needed by ES7000 platform
*/
if (ioapic_renumber_irq)
- irq = ioapic_renumber_irq(apic, irq);
+ gsi = ioapic_renumber_irq(apic, gsi);
+ irq = gsi;
}
#ifdef CONFIG_X86_32
--
1.6.5.2.143.g8cc62
--
From: Eric W. Biederman <ebiederm@xmission.com>
Now that all ioapic registration happens in mp_register_ioapic we can
move the calculation of nr_ioapic_registers there from enable_IO_APIC.
The number of ioapic registers is already calucated in mp_register_ioapic
so all that really needs to be done is to save the caluclated value
in nr_ioapic_registers.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/apic/io_apic.c | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index a979a00..0515f26 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1944,20 +1944,8 @@ static struct { int pin, apic; } ioapic_i8259 = { -1, -1 };
void __init enable_IO_APIC(void)
{
- union IO_APIC_reg_01 reg_01;
int i8259_apic, i8259_pin;
int apic;
- unsigned long flags;
-
- /*
- * The number of IO-APIC IRQ registers (== #pins):
- */
- for (apic = 0; apic < nr_ioapics; apic++) {
- raw_spin_lock_irqsave(&ioapic_lock, flags);
- reg_01.raw = io_apic_read(apic, 1);
- raw_spin_unlock_irqrestore(&ioapic_lock, flags);
- nr_ioapic_registers[apic] = reg_01.bits.entries+1;
- }
if (!legacy_pic->nr_legacy_irqs)
return;
@@ -4280,6 +4268,7 @@ static int bad_ioapic(unsigned long address)
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
{
int idx = 0;
+ int entries;
if (bad_ioapic(address))
return;
@@ -4298,9 +4287,14 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
* Build basic GSI lookup table to facilitate gsi->io_apic lookups
* and to prevent reprogramming of IOAPIC pins (PCI GSIs).
*/
+ entries = io_apic_get_redir_entries(idx);
mp_gsi_routing[idx].gsi_base = gsi_base;
- mp_gsi_routing[idx].gsi_end = gsi_base +
- io_apic_get_redir_entries(idx);
+ mp_gsi_routing[idx].gsi_end = gsi_base + entries;
+
+ /*
+ * The number of IO-APIC IRQ registers ...From: Eric W. Biederman <ebiederm@xmission.com>
Currently acpi_sci_ioapic_setup calls mp_override_legacy_irq with
bus_irq == gsi, which is wrong if we are comming from an override
Instead pass the bus_irq into acpi_sci_ioapic_setup.
This fix was inspired by a similar fix from:
Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/acpi/boot.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index f96060d..1742888 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -312,7 +312,7 @@ acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end)
/*
* Parse Interrupt Source Override for the ACPI SCI
*/
-static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
+static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger, u32 gsi)
{
if (trigger == 0) /* compatible SCI trigger is level */
trigger = 3;
@@ -332,7 +332,7 @@ static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
* If GSI is < 16, this will update its flags,
* else it will create a new mp_irqs[] entry.
*/
- mp_override_legacy_irq(gsi, polarity, trigger, gsi);
+ mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
/*
* stash over-ride to indicate we've been here
@@ -356,9 +356,10 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header * header,
acpi_table_print_madt_entry(header);
if (intsrc->source_irq == acpi_gbl_FADT.sci_interrupt) {
- acpi_sci_ioapic_setup(intsrc->global_irq,
+ acpi_sci_ioapic_setup(intsrc->source_irq,
intsrc->inti_flags & ACPI_MADT_POLARITY_MASK,
- (intsrc->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2);
+ (intsrc->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2,
+ intsrc->global_irq);
return 0;
}
@@ -1161,7 +1162,8 @@ static int __init ...From: Eric W. Biederman <ebiederm@xmission.com>
Long ago MP_ioapic_info was the primary way of setting up our
ioapic data structures and mp_register_ioapic was a compatibility
shim for acpi code. Now the situation is reversed and
and mp_register_ioapic is the primary way of setting up our
ioapic data structures.
Keep the setting up of ioapic data structures uniform by
having mp_register_ioapic call mp_register_ioapic.
This changes a few fields:
- type: is now hardset to MP_IOAPIC but type had to
bey MP_IOAPIC or MP_ioapic_info would not have been called.
- flags: is now hard coded to MPC_APIC_USABLE.
We require flags to contain at least MPC_APIC_USEBLE in
MP_ioapic_info and we don't ever examine flags so dropping
a few flags that might possibly exist that we have never
used is harmless.
- apicaddr: Unchanged
- apicver: Read from the ioapic instead of using the cached
hardware value in the MP table. The real hardware value
will be more accurate.
- apicid: Now verified to be unique and changed if it is not.
If the BIOS got this right this is a noop. If the BIOS did
not fixing things appears to be the better solution.
This adds gsi_base and gsi_end values to our ioapics defined with
the mpatable, which will make our lives simpler later since
we can always assume gsi_base and gsi_end are valid.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/mpparse.c | 25 +------------------------
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index a2c1edd..c0de938 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -115,21 +115,6 @@ static void __init MP_bus_info(struct mpc_bus *m)
printk(KERN_WARNING "Unknown bustype %s - ignoring\n", str);
}
-static int bad_ioapic(unsigned long address)
-{
- if (nr_ioapics >= MAX_IO_APICS) {
- printk(KERN_ERR "ERROR: Max # of I/O APICs (%d) exceeded "
- "(found %d)\n", ...From: Eric W. Biederman <ebiederm@xmission.com>
Add the global variable gsi_end and teach mp_register_ioapic
to keep it uptodate as we add more ioapics into the system.
ioapics can only be added early in boot so the code that
runs later can treat gsi_end as a constant.
Remove the have hacks in sfi.c to second guess mp_register_ioapic
by keeping t's own running total of how many gsi's have been seen,
and instead use the gsi_end.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 1 +
arch/x86/kernel/apic/io_apic.c | 6 ++++++
arch/x86/kernel/sfi.c | 4 +---
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index feeaf0d..37b0f2b 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -184,6 +184,7 @@ struct mp_ioapic_gsi{
u32 gsi_end;
};
extern struct mp_ioapic_gsi mp_gsi_routing[];
+extern u32 gsi_end;
int mp_find_ioapic(u32 gsi);
int mp_find_ioapic_pin(int ioapic, u32 gsi);
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 32cea57..a979a00 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -88,6 +88,9 @@ int nr_ioapics;
/* IO APIC gsi routing info */
struct mp_ioapic_gsi mp_gsi_routing[MAX_IO_APICS];
+/* One past the last gsi number used */
+u32 gsi_end;
+
/* MP IRQ source entries */
struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
@@ -4299,6 +4302,9 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
mp_gsi_routing[idx].gsi_end = gsi_base +
io_apic_get_redir_entries(idx);
+ if (mp_gsi_routing[idx].gsi_end > gsi_end)
+ gsi_end = mp_gsi_routing[idx].gsi_end;
+
printk(KERN_INFO "IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
"GSI %d-%d\n", idx, mp_ioapics[idx].apicid,
mp_ioapics[idx].apicver, ...From: Eric W. Biederman <ebiederm@xmission.com>
In perverse acpi implementations the isa irqs are not identity mapped
to the first 16 gsi. Furthermore at least the extended interrupt
resource capability may return gsi's and not isa irqs. So since
what we get from acpi is a gsi teach acpi_get_overrride_irq to
operate on a gsi instead of an isa_irq.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/apic/io_apic.c | 23 ++++++++++++++---------
include/linux/acpi.h | 4 ++--
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e4e0ddc..54ba1f7 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -4073,22 +4073,27 @@ int __init io_apic_get_version(int ioapic)
return reg_01.bits.version;
}
-int acpi_get_override_irq(int bus_irq, int *trigger, int *polarity)
+int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity)
{
- int i;
+ int ioapic, pin, idx;
if (skip_ioapic_setup)
return -1;
- for (i = 0; i < mp_irq_entries; i++)
- if (mp_irqs[i].irqtype == mp_INT &&
- mp_irqs[i].srcbusirq == bus_irq)
- break;
- if (i >= mp_irq_entries)
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0)
+ return -1;
+
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+ if (pin < 0)
+ return -1;
+
+ idx = find_irq_entry(ioapic, pin, mp_INT);
+ if (idx < 0)
return -1;
- *trigger = irq_trigger(i);
- *polarity = irq_polarity(i);
+ *trigger = irq_trigger(idx);
+ *polarity = irq_polarity(idx);
return 0;
}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 7a937da..3da73f5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -119,9 +119,9 @@ int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
#ifdef CONFIG_X86_IO_APIC
-extern int acpi_get_override_irq(int bus_irq, int *trigger, int *polarity);
+extern int ...It appears there are a few systems in the wild that use acpi
interrupt source overrides to report a gsi > 16 is an isa irq.
This breaks all kinds of assumptions I figure any BIOS doing that
probably should be shot as that is very much not a conservative position.
That said acpi appears to allow this insanity and on the basis of being
liberal in what we accept we should try to do something reasonable, and
keep our notions of gsi, isa irq, and linux irq as straight as we can.
To that end this patchset slightly modifies the gsi to linux irq
mapping. Making it a 1 to 1 identity mapping except for the first 16
gsis. If those gsis are isa irqs (the typical and default acpi
configuration) they will be mapped into the first 16 irqs. If those
first 16 gsis are not isa irqs they will be given a linux irq number
just past the last gsi. Allowing us the chance to use them.
This patchset is my attempt to straighten out our understanding of which
kind of irq name is used where and the cleanups used to get there.
Thanks to Yinghai Lu <yinghai@kernel.org> for taking the first stab at
this and finding that there is a real world problem here. This patchset
is inspired by his work, but little of it remains the same.
This patchset lies in the weird world between the acpi and x86 and ia64.
Since most of the changes are x86 related I think it makes most sense
to go via the x86 tree.
v2: Recognize that gsi_end is last gsi for an ioapic not one past the end.
Since I use gsi_end widely in my patchset a respin of many of the patches
made sense.
Eric W. Biederman (15):
x86 acpi/irq: Introduce apci_isa_irq_to_gsi
x86 acpi/irq: Teach acpi_get_override_irq to take a gsi not an isa_irq
x86 acpi/irq: pci device dev->irq is an isa irq not a gsi
x86 acpi/irq: Fix acpi_sci_ioapic_setup so it has both bus_irq and gsi
x86 acpi/irq: Generalize mp_config_acpi_legacy_irqs
x86 ioapic: Only export mp_find_ioapic and mp_find_ioapic_pin in io_apic.h
...From: Eric W. Biederman <ebiederm@xmission.com>
Remove the assumption that there is not an override for isa irq 0.
Instead lookup the gsi and from that lookup the ioapic and pin of each
isa irq indivdually.
In general this should not have any behavioural affect but in
perverse cases this gets all of the details correct, instead of
doing something weird.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/acpi/boot.c | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 1742888..9c48e99 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -960,8 +960,6 @@ void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger, u32 gsi)
void __init mp_config_acpi_legacy_irqs(void)
{
int i;
- int ioapic;
- unsigned int dstapic;
struct mpc_intsrc mp_irq;
#if defined (CONFIG_MCA) || defined (CONFIG_EISA)
@@ -982,19 +980,27 @@ void __init mp_config_acpi_legacy_irqs(void)
#endif
/*
- * Locate the IOAPIC that manages the ISA IRQs (0-15).
- */
- ioapic = mp_find_ioapic(0);
- if (ioapic < 0)
- return;
- dstapic = mp_ioapics[ioapic].apicid;
-
- /*
* Use the default configuration for the IRQs 0-15. Unless
* overridden by (MADT) interrupt source override entries.
*/
for (i = 0; i < 16; i++) {
+ int ioapic, pin;
+ unsigned int dstapic;
int idx;
+ u32 gsi;
+
+ /* Locate the gsi that irq i maps to. */
+ if (acpi_isa_irq_to_gsi(i, &gsi))
+ continue;
+
+ /*
+ * Locate the IOAPIC that manages the ISA IRQ.
+ */
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0)
+ continue;
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+ dstapic = mp_ioapics[ioapic].apicid;
for (idx = 0; idx < mp_irq_entries; idx++) {
struct mpc_intsrc *irq = mp_irqs + idx;
@@ -1004,7 +1010,7 @@ void __init mp_config_acpi_legacy_irqs(void)
break;
/* Do we already have a ...Commit-ID: 0fd52670fb6400be0996ac492b5ed77f3d83d69a Gitweb: http://git.kernel.org/tip/0fd52670fb6400be0996ac492b5ed77f3d83d69a Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:06 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:38 -0700 x86, acpi/irq: Generalize mp_config_acpi_legacy_irqs Remove the assumption that there is not an override for isa irq 0. Instead lookup the gsi and from that lookup the ioapic and pin of each isa irq indivdually. In general this should not have any behavioural affect but in perverse cases this gets all of the details correct, instead of doing something weird. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-5-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/acpi/boot.c | 30 ++++++++++++++++++------------ 1 files changed, 18 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 0a036dc..3ee92f2 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -961,8 +961,6 @@ void __init mp_override_legacy_irq(u8 bus_irq, u8 polarity, u8 trigger, u32 gsi) void __init mp_config_acpi_legacy_irqs(void) { int i; - int ioapic; - unsigned int dstapic; struct mpc_intsrc mp_irq; #if defined (CONFIG_MCA) || defined (CONFIG_EISA) @@ -983,19 +981,27 @@ void __init mp_config_acpi_legacy_irqs(void) #endif /* - * Locate the IOAPIC that manages the ISA IRQs (0-15). - */ - ioapic = mp_find_ioapic(0); - if (ioapic < 0) - return; - dstapic = mp_ioapics[ioapic].apicid; - - /* * Use the default configuration for the IRQs 0-15. Unless * overridden by (MADT) interrupt source override entries. */ for (i = 0; i < 16; i++) { + int ioapic, pin; + unsigned int dstapic; int idx; + u32 gsi; + + /* Locate the gsi that irq i maps to. */ + if (acpi_isa_irq_to_gsi(i, ...
From: Eric W. Biederman <ebiederm@xmission.com>
Use the global gsi_end value now that all ioapics have
valid gsi numbers instead of a combination of acpi_probe_gsi
and walking all of the ioapics and couting their number of
entries by hand if acpi_probe_gsi gave us an answer we did
not like.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/mpspec.h | 6 ------
arch/x86/kernel/acpi/boot.c | 23 -----------------------
arch/x86/kernel/apic/io_apic.c | 17 +++--------------
3 files changed, 3 insertions(+), 43 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index 29994f0..c82868e 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -105,12 +105,6 @@ extern void mp_config_acpi_legacy_irqs(void);
struct device;
extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level,
int active_high_low);
-extern int acpi_probe_gsi(void);
-#else /* !CONFIG_ACPI: */
-static inline int acpi_probe_gsi(void)
-{
- return 0;
-}
#endif /* CONFIG_ACPI */
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 9c48e99..0e514a1 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -875,29 +875,6 @@ static int __init acpi_parse_madt_lapic_entries(void)
extern int es7000_plat;
#endif
-int __init acpi_probe_gsi(void)
-{
- int idx;
- int gsi;
- int max_gsi = 0;
-
- if (acpi_disabled)
- return 0;
-
- if (!acpi_ioapic)
- return 0;
-
- max_gsi = 0;
- for (idx = 0; idx < nr_ioapics; idx++) {
- gsi = mp_gsi_routing[idx].gsi_end;
-
- if (gsi > max_gsi)
- max_gsi = gsi;
- }
-
- return max_gsi + 1;
-}
-
static void assign_to_mp_irq(struct mpc_intsrc *m,
struct mpc_intsrc *mp_irq)
{
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 764c74c..6d6def8 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ ...Commit-ID: 4afc51a835d3aeba11c35090f524e05c84586d27 Gitweb: http://git.kernel.org/tip/4afc51a835d3aeba11c35090f524e05c84586d27 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:14 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:35:11 -0700 x86, ioapic: Simplify probe_nr_irqs_gsi. Use the global gsi_end value now that all ioapics have valid gsi numbers instead of a combination of acpi_probe_gsi and walking all of the ioapics and couting their number of entries by hand if acpi_probe_gsi gave us an answer we did not like. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-13-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/mpspec.h | 6 ------ arch/x86/kernel/acpi/boot.c | 23 ----------------------- arch/x86/kernel/apic/io_apic.c | 17 +++-------------- 3 files changed, 3 insertions(+), 43 deletions(-) diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h index 29994f0..c82868e 100644 --- a/arch/x86/include/asm/mpspec.h +++ b/arch/x86/include/asm/mpspec.h @@ -105,12 +105,6 @@ extern void mp_config_acpi_legacy_irqs(void); struct device; extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level, int active_high_low); -extern int acpi_probe_gsi(void); -#else /* !CONFIG_ACPI: */ -static inline int acpi_probe_gsi(void) -{ - return 0; -} #endif /* CONFIG_ACPI */ #define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_APICS) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 3ee92f2..07a63ce 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -876,29 +876,6 @@ static int __init acpi_parse_madt_lapic_entries(void) extern int es7000_plat; #endif -int __init acpi_probe_gsi(void) -{ - int idx; - int gsi; - int max_gsi = 0; - - if (acpi_disabled) - return 0; - - if ...
From: Eric W. Biederman <ebiederm@xmission.com>
Now that the generic irq layer is performing the exact same remapping as
io_apic_renumber_irq we can kill this weird es7000 specific function.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 1 -
arch/x86/kernel/acpi/boot.c | 5 -----
arch/x86/kernel/apic/es7000_32.c | 19 -------------------
arch/x86/kernel/apic/io_apic.c | 6 ------
4 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 37b0f2b..9da192a 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -159,7 +159,6 @@ struct io_apic_irq_attr;
extern int io_apic_set_pci_routing(struct device *dev, int irq,
struct io_apic_irq_attr *irq_attr);
void setup_IO_APIC_irq_extra(u32 gsi);
-extern int (*ioapic_renumber_irq)(int ioapic, int irq);
extern void ioapic_init_mappings(void);
extern void ioapic_insert_resources(void);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index c4b4bd9..614f3a7 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1116,11 +1116,6 @@ int mp_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
ioapic_pin = mp_find_ioapic_pin(ioapic, gsi);
-#ifdef CONFIG_X86_32
- if (ioapic_renumber_irq)
- gsi = ioapic_renumber_irq(ioapic, gsi);
-#endif
-
if (ioapic_pin > MP_MAX_IOAPIC_PIN) {
printk(KERN_ERR "Invalid reference to IOAPIC pin "
"%d-%d\n", mp_ioapics[ioapic].apicid,
diff --git a/arch/x86/kernel/apic/es7000_32.c b/arch/x86/kernel/apic/es7000_32.c
index dd2b5f2..7a63d47 100644
--- a/arch/x86/kernel/apic/es7000_32.c
+++ b/arch/x86/kernel/apic/es7000_32.c
@@ -130,24 +130,6 @@ int es7000_plat;
static unsigned int base;
-static int
-es7000_rename_gsi(int ioapic, int gsi)
-{
- if (es7000_plat == ES7000_ZORRO)
- return gsi;
-
- if (!base) {
- int i;
- for ...Commit-ID: 7b20bd5fb902088579af4e70f7f802b93181a628 Gitweb: http://git.kernel.org/tip/7b20bd5fb902088579af4e70f7f802b93181a628 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:16 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:35:20 -0700 x86, irq: Kill io_apic_renumber_irq Now that the generic irq layer is performing the exact same remapping as io_apic_renumber_irq we can kill this weird es7000 specific function. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-15-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/io_apic.h | 1 - arch/x86/kernel/acpi/boot.c | 5 ----- arch/x86/kernel/apic/es7000_32.c | 19 ------------------- arch/x86/kernel/apic/io_apic.c | 6 ------ 4 files changed, 0 insertions(+), 31 deletions(-) diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index 37b0f2b..9da192a 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -159,7 +159,6 @@ struct io_apic_irq_attr; extern int io_apic_set_pci_routing(struct device *dev, int irq, struct io_apic_irq_attr *irq_attr); void setup_IO_APIC_irq_extra(u32 gsi); -extern int (*ioapic_renumber_irq)(int ioapic, int irq); extern void ioapic_init_mappings(void); extern void ioapic_insert_resources(void); diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 325fbba..9a5ed58 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1117,11 +1117,6 @@ int mp_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity) ioapic_pin = mp_find_ioapic_pin(ioapic, gsi); -#ifdef CONFIG_X86_32 - if (ioapic_renumber_irq) - gsi = ioapic_renumber_irq(ioapic, gsi); -#endif - if (ioapic_pin > MP_MAX_IOAPIC_PIN) { printk(KERN_ERR "Invalid reference to IOAPIC pin " "%d-%d\n", ...
From: Eric W. Biederman <ebiederm@xmission.com>
Now that all ioapics have valid gsi_base values use this to
accellerate pin_2_irq. In the case of acpi this also ensures
that pin_2_irq will compute the same irq value for an ioapic
pin as acpi will.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/apic/io_apic.c | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c505fe0..764c74c 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1018,7 +1018,7 @@ static inline int irq_trigger(int idx)
int (*ioapic_renumber_irq)(int ioapic, int irq);
static int pin_2_irq(int idx, int apic, int pin)
{
- int irq, i;
+ int irq;
int bus = mp_irqs[idx].srcbus;
/*
@@ -1030,18 +1030,13 @@ static int pin_2_irq(int idx, int apic, int pin)
if (test_bit(bus, mp_bus_not_pci)) {
irq = mp_irqs[idx].srcbusirq;
} else {
- /*
- * PCI IRQs are mapped in order
- */
- i = irq = 0;
- while (i < apic)
- irq += nr_ioapic_registers[i++];
- irq += pin;
+ u32 gsi = mp_gsi_routing[apic].gsi_base + pin;
/*
* For MPS mode, so far only needed by ES7000 platform
*/
if (ioapic_renumber_irq)
- irq = ioapic_renumber_irq(apic, irq);
+ gsi = ioapic_renumber_irq(apic, gsi);
+ irq = gsi;
}
#ifdef CONFIG_X86_32
--
1.6.5.2.143.g8cc62
--
Commit-ID: d464207c4fdd70c2a0febd4f9c58206fa915bb36 Gitweb: http://git.kernel.org/tip/d464207c4fdd70c2a0febd4f9c58206fa915bb36 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:13 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:35:08 -0700 x86, ioapic: Optimize pin_2_irq Now that all ioapics have valid gsi_base values use this to accellerate pin_2_irq. In the case of acpi this also ensures that pin_2_irq will compute the same irq value for an ioapic pin as acpi will. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-12-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/apic/io_apic.c | 13 ++++--------- 1 files changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index dae9240..0d35f46 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1019,7 +1019,7 @@ static inline int irq_trigger(int idx) int (*ioapic_renumber_irq)(int ioapic, int irq); static int pin_2_irq(int idx, int apic, int pin) { - int irq, i; + int irq; int bus = mp_irqs[idx].srcbus; /* @@ -1031,18 +1031,13 @@ static int pin_2_irq(int idx, int apic, int pin) if (test_bit(bus, mp_bus_not_pci)) { irq = mp_irqs[idx].srcbusirq; } else { - /* - * PCI IRQs are mapped in order - */ - i = irq = 0; - while (i < apic) - irq += nr_ioapic_registers[i++]; - irq += pin; + u32 gsi = mp_gsi_routing[apic].gsi_base + pin; /* * For MPS mode, so far only needed by ES7000 platform */ if (ioapic_renumber_irq) - irq = ioapic_renumber_irq(apic, irq); + gsi = ioapic_renumber_irq(apic, gsi); + irq = gsi; } #ifdef CONFIG_X86_32 --
From: Eric W. Biederman <ebiederm@xmission.com>
ACPI irq source overrides are allowed for the 16 isa irqs and are
allowed to map any gsi to any isa irq. A few motherboards have been
seen to take advantage of this and put the isa irqs on the 2nd or
3rd ioapic. This causes some problems, most notably the fact
that we can not use any gsi < 16.
To correct this move the gsis that are not isa irqs and have
a gsi number < 16 into the linux irq space just past gsi_end.
This is what the es7000 platform is doing today. Moving only the
low 16 gsis above the rest of the gsi's only penalizes weird
platforms, leaving sane acpi implementations with a 1-1 mapping
of gsis and irqs.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/acpi/boot.c | 57 +++++++++++++++++++++++++++++++++++++---
arch/x86/kernel/apic/io_apic.c | 8 ++++-
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0e514a1..c4b4bd9 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -92,6 +92,53 @@ static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC;
+/*
+ * ISA irqs by default are the first 16 gsis but can be
+ * any gsi as specified by an interrupt source override.
+ */
+static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = {
+ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
+};
+
+static unsigned int gsi_to_irq(unsigned int gsi)
+{
+ unsigned int irq = gsi + NR_IRQS_LEGACY;
+ unsigned int i;
+
+ for (i = 0; i < NR_IRQS_LEGACY; i++) {
+ if (isa_irq_to_gsi[i] == gsi) {
+ return i;
+ }
+ }
+
+ /* Provide an identity mapping of gsi == irq
+ * except on truly weird platforms that have
+ * non isa irqs in the first 16 gsis.
+ */
+ if (gsi >= NR_IRQS_LEGACY)
+ irq = gsi;
+ else
+ irq = gsi_end + 1 + gsi;
+
+ return irq;
+}
+
+static u32 irq_to_gsi(int ...Commit-ID: 988856ee1623bd37e384105f7bb2b7fe44c009f6 Gitweb: http://git.kernel.org/tip/988856ee1623bd37e384105f7bb2b7fe44c009f6 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:15 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:35:17 -0700 x86, acpi/irq: Handle isa irqs that are not identity mapped to gsi's. ACPI irq source overrides are allowed for the 16 isa irqs and are allowed to map any gsi to any isa irq. A few motherboards have been seen to take advantage of this and put the isa irqs on the 2nd or 3rd ioapic. This causes some problems, most notably the fact that we can not use any gsi < 16. To correct this move the gsis that are not isa irqs and have a gsi number < 16 into the linux irq space just past gsi_end. This is what the es7000 platform is doing today. Moving only the low 16 gsis above the rest of the gsi's only penalizes weird platforms, leaving sane acpi implementations with a 1-1 mapping of gsis and irqs. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-14-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/acpi/boot.c | 57 +++++++++++++++++++++++++++++++++++++--- arch/x86/kernel/apic/io_apic.c | 8 ++++- 2 files changed, 59 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 07a63ce..325fbba 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -94,6 +94,53 @@ enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_PIC; /* + * ISA irqs by default are the first 16 gsis but can be + * any gsi as specified by an interrupt source override. + */ +static u32 isa_irq_to_gsi[NR_IRQS_LEGACY] __read_mostly = { + 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 +}; + +static unsigned int gsi_to_irq(unsigned int gsi) +{ + unsigned int irq = gsi + NR_IRQS_LEGACY; + unsigned int ...
here should be can you use legacy_irq->nr_legacy_irqs instead of NR_IRQS_LEGACY ? YH --
YH noticed that the function irq_to_gsi has an off by one error when translating high irq numbers to gsis. Today this bug is harmless because all of the callers restrict their input to the first 16 irqs so this bug does not matter, but we should fix it to avoid confusion and later. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86/kernel/acpi/boot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index c9a5d3f..78222c8 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -132,7 +132,7 @@ static u32 irq_to_gsi(int irq) else if (irq <= gsi_end) gsi = irq; else if (irq <= (gsi_end + NR_IRQS_LEGACY)) - gsi = irq - gsi_end; + gsi = irq - (gsi_end + 1); else gsi = 0xffffffff; -- 1.6.5.2.143.g8cc62 --
Please use the Reported-by tag. Thanks, Ingo --
No. legacy_irq->nr_legacy_irqs is just for dealing with hardware that does not have i8259 pics. Here I am reserving 16 irqs above the gsi range in case we get a weird gsi to isa irq mapping. Currently the sfi spec doesn't mention anything explicitly. I took a quick read through it and sfi and I presume Moorestown is talking about non pci irqs. So I would not be surprised if we didn't have isa device drivers running on platforms without i8259s. Currently the code had a small bug dealing with multiple ioapics and the spec really is incomplete about how you map irqs from pci devices to interrupts. So it looks like SFI and Moorestown are more a lab experiment than real hardware at the moment. So I expect when it gets completely fleshed out we will have to jump through a similar set of hoops as we do with acpi to ensure the first 16 irqs are not used for anything except isa irqs. Eric --
I don't know if it is "just" for this purpose. Quite on the contrary. In fact, the fact that NR_IRQS_LEGACY is showing up at all looks like a But that 16 is exactly because those are the (platform-specific) legacy I'm confused about the above. Where do you see any mention to fixed Moorestown hardware certainly exists, although not all the support is upstream yet. Either which way, anything which perpetuates NR_IRQS_LEGACY as a compile-time constant is begging for people to get things wrong, and it really needs to go away. -hpa --
yes, it should be replaced legacy_irq->nr_legacy_irs to make Moorestown to have sane irq index. otherwise gsi_to_irq will mapping all [0, 15] to start from nr_irqs_gsi. Thanks Yinghai --
FYI, the patchset causes this build error with certain configs: arch/x86/kernel/acpi/boot.c:122: error: 'gsi_end' undeclared (first use in this function) arch/x86/kernel/acpi/boot.c:122: error: (Each undeclared identifier is reported only once arch/x86/kernel/acpi/boot.c:122: error: for each function it appears in.) arch/x86/kernel/acpi/boot.c:133: error: 'gsi_end' undeclared (first use in this function) Ingo --
What configuration supports acpi and doesn't support ioapics? Eric --
an UP kernel with ACPI turned on for example. Ingo --
Oops. My recent changes introducing a global gsi_end variable failed
to take into account the case of using acpi on a system not built to
support IO_APICs, causing the build to fail. Define gsi_end to 15 when
CONFIG_X86_IO_APIC is not set to avoid compile errors.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 9da192a..63cb409 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -197,6 +197,7 @@ static const int timer_through_8259 = 0;
static inline void ioapic_init_mappings(void) { }
static inline void ioapic_insert_resources(void) { }
static inline void probe_nr_irqs_gsi(void) { }
+#define gsi_end (NR_IRQS_LEGACY - 1)
static inline int mp_find_ioapic(u32 gsi) { return 0; }
struct io_apic_irq_attr;
--
1.6.5.2.143.g8cc62
--
Applied to tip:x86/irq, thanks Eric! Ingo --
Commit-ID: 4f47b4c9f0b711bf84adb8c27774ae80d346b628 Gitweb: http://git.kernel.org/tip/4f47b4c9f0b711bf84adb8c27774ae80d346b628 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Wed, 5 May 2010 13:22:25 -0700 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Thu, 6 May 2010 08:17:51 +0200 x86, acpi/irq: Define gsi_end when X86_IO_APIC is undefined My recent changes introducing a global gsi_end variable failed to take into account the case of using acpi on a system not built to support IO_APICs, causing the build to fail. Define gsi_end to 15 when CONFIG_X86_IO_APIC is not set to avoid compile errors. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Yinghai Lu <yinghai@kernel.org> LKML-Reference: <m1tyqm14la.fsf_-_@fess.ebiederm.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/include/asm/io_apic.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index 9da192a..63cb409 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -197,6 +197,7 @@ static const int timer_through_8259 = 0; static inline void ioapic_init_mappings(void) { } static inline void ioapic_insert_resources(void) { } static inline void probe_nr_irqs_gsi(void) { } +#define gsi_end (NR_IRQS_LEGACY - 1) static inline int mp_find_ioapic(u32 gsi) { return 0; } struct io_apic_irq_attr; --
From: Eric W. Biederman <ebiederm@xmission.com>
Add the global variable gsi_end and teach mp_register_ioapic
to keep it uptodate as we add more ioapics into the system.
ioapics can only be added early in boot so the code that
runs later can treat gsi_end as a constant.
Remove the have hacks in sfi.c to second guess mp_register_ioapic
by keeping t's own running total of how many gsi's have been seen,
and instead use the gsi_end.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 1 +
arch/x86/kernel/apic/io_apic.c | 6 ++++++
arch/x86/kernel/sfi.c | 4 +---
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index feeaf0d..37b0f2b 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -184,6 +184,7 @@ struct mp_ioapic_gsi{
u32 gsi_end;
};
extern struct mp_ioapic_gsi mp_gsi_routing[];
+extern u32 gsi_end;
int mp_find_ioapic(u32 gsi);
int mp_find_ioapic_pin(int ioapic, u32 gsi);
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 4611c43..71988c5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -88,6 +88,9 @@ int nr_ioapics;
/* IO APIC gsi routing info */
struct mp_ioapic_gsi mp_gsi_routing[MAX_IO_APICS];
+/* The last gsi number used */
+u32 gsi_end;
+
/* MP IRQ source entries */
struct mpc_intsrc mp_irqs[MAX_IRQ_SOURCES];
@@ -4303,6 +4306,9 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
mp_gsi_routing[idx].gsi_end = gsi_base +
io_apic_get_redir_entries(idx) - 1;
+ if (mp_gsi_routing[idx].gsi_end > gsi_end)
+ gsi_end = mp_gsi_routing[idx].gsi_end;
+
printk(KERN_INFO "IOAPIC[%d]: apic_id %d, version %d, address 0x%x, "
"GSI %d-%d\n", idx, mp_ioapics[idx].apicid,
mp_ioapics[idx].apicver, ...Commit-ID: 5777372af5c929b8f3c706ed7b295b7279537c88 Gitweb: http://git.kernel.org/tip/5777372af5c929b8f3c706ed7b295b7279537c88 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:10 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:56 -0700 x86, ioapic: Teach mp_register_ioapic to compute a global gsi_end Add the global variable gsi_end and teach mp_register_ioapic to keep it uptodate as we add more ioapics into the system. ioapics can only be added early in boot so the code that runs later can treat gsi_end as a constant. Remove the have hacks in sfi.c to second guess mp_register_ioapic by keeping t's own running total of how many gsi's have been seen, and instead use the gsi_end. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-9-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/io_apic.h | 1 + arch/x86/kernel/apic/io_apic.c | 6 ++++++ arch/x86/kernel/sfi.c | 4 +--- 3 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index feeaf0d..37b0f2b 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -184,6 +184,7 @@ struct mp_ioapic_gsi{ u32 gsi_end; }; extern struct mp_ioapic_gsi mp_gsi_routing[]; +extern u32 gsi_end; int mp_find_ioapic(u32 gsi); int mp_find_ioapic_pin(int ioapic, u32 gsi); void __init mp_register_ioapic(int id, u32 address, u32 gsi_base); diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 9ab9762..f807255 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -89,6 +89,9 @@ int nr_ioapics; /* IO APIC gsi routing info */ struct mp_ioapic_gsi mp_gsi_routing[MAX_IO_APICS]; +/* The last gsi number used */ +u32 gsi_end; + /* MP IRQ source entries */ struct mpc_intsrc ...
From: Eric W. Biederman <ebiederm@xmission.com>
Now that all ioapic registration happens in mp_register_ioapic we can
move the calculation of nr_ioapic_registers there from enable_IO_APIC.
The number of ioapic registers is already calucated in mp_register_ioapic
so all that really needs to be done is to save the caluclated value
in nr_ioapic_registers.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/apic/io_apic.c | 22 ++++++++--------------
1 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 71988c5..c505fe0 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1944,20 +1944,8 @@ static struct { int pin, apic; } ioapic_i8259 = { -1, -1 };
void __init enable_IO_APIC(void)
{
- union IO_APIC_reg_01 reg_01;
int i8259_apic, i8259_pin;
int apic;
- unsigned long flags;
-
- /*
- * The number of IO-APIC IRQ registers (== #pins):
- */
- for (apic = 0; apic < nr_ioapics; apic++) {
- raw_spin_lock_irqsave(&ioapic_lock, flags);
- reg_01.raw = io_apic_read(apic, 1);
- raw_spin_unlock_irqrestore(&ioapic_lock, flags);
- nr_ioapic_registers[apic] = reg_01.bits.entries+1;
- }
if (!legacy_pic->nr_legacy_irqs)
return;
@@ -4284,6 +4272,7 @@ static int bad_ioapic(unsigned long address)
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
{
int idx = 0;
+ int entries;
if (bad_ioapic(address))
return;
@@ -4302,9 +4291,14 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base)
* Build basic GSI lookup table to facilitate gsi->io_apic lookups
* and to prevent reprogramming of IOAPIC pins (PCI GSIs).
*/
+ entries = io_apic_get_redir_entries(idx);
mp_gsi_routing[idx].gsi_base = gsi_base;
- mp_gsi_routing[idx].gsi_end = gsi_base +
- io_apic_get_redir_entries(idx) - 1;
+ mp_gsi_routing[idx].gsi_end = gsi_base + entries - 1;
+
+ /*
+ * The number of IO-APIC IRQ ...Commit-ID: 7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af Gitweb: http://git.kernel.org/tip/7716a5c4ff5f1f3dc5e9edcab125cbf7fceef0af Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:12 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:35:03 -0700 x86, ioapic: Move nr_ioapic_registers calculation to mp_register_ioapic. Now that all ioapic registration happens in mp_register_ioapic we can move the calculation of nr_ioapic_registers there from enable_IO_APIC. The number of ioapic registers is already calucated in mp_register_ioapic so all that really needs to be done is to save the caluclated value in nr_ioapic_registers. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-11-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/apic/io_apic.c | 22 ++++++++-------------- 1 files changed, 8 insertions(+), 14 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index f807255..dae9240 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1953,20 +1953,8 @@ static struct { int pin, apic; } ioapic_i8259 = { -1, -1 }; void __init enable_IO_APIC(void) { - union IO_APIC_reg_01 reg_01; int i8259_apic, i8259_pin; int apic; - unsigned long flags; - - /* - * The number of IO-APIC IRQ registers (== #pins): - */ - for (apic = 0; apic < nr_ioapics; apic++) { - raw_spin_lock_irqsave(&ioapic_lock, flags); - reg_01.raw = io_apic_read(apic, 1); - raw_spin_unlock_irqrestore(&ioapic_lock, flags); - nr_ioapic_registers[apic] = reg_01.bits.entries+1; - } if (!legacy_pic->nr_legacy_irqs) return; @@ -4293,6 +4281,7 @@ static int bad_ioapic(unsigned long address) void __init mp_register_ioapic(int id, u32 address, u32 gsi_base) { int idx = 0; + int entries; if (bad_ioapic(address)) return; @@ -4311,9 +4300,14 @@ void __init ...
From: Eric W. Biederman <ebiederm@xmission.com>
There are a number of cases where the current code makes the assumption
that isa irqs identity map to the first 16 acpi global system intereupts.
In most instances that assumption is correct as that is the required
behaviour in dual i8259 mode and the default behavior in ioapic mode.
However there are some systems out there that take advantage of acpis
interrupt remapping for the isa irqs to have a completely different
mapping of isa_irq to gsi.
Introduce acpi_isa_irq_to_gsi to perform this mapping explicitly in the
code that needs it. Initially this will be just the current assumed
identity mapping to ensure it's introduction does not cause regressions.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/ia64/kernel/acpi.c | 8 ++++++++
arch/x86/kernel/acpi/boot.c | 8 ++++++++
include/linux/acpi.h | 1 +
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index f1c9f70..16921bd 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -784,6 +784,14 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
return 0;
}
+int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
+{
+ if (isa_irq >= 16)
+ return -1;
+ *gsi = isa_irq;
+ return 0;
+}
+
/*
* ACPI based hotplug CPU support
*/
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0061ea2..f96060d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -457,6 +457,14 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
return 0;
}
+int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
+{
+ if (isa_irq >= 16)
+ return -1;
+ *gsi = isa_irq;
+ return 0;
+}
+
/*
* success: return IRQ number (>=0)
* failure: return < 0
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index b926afe..7a937da 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -116,6 +116,7 @@ ...Commit-ID: 2c2df8418ac7908eec4558407b83f16739006c54 Gitweb: http://git.kernel.org/tip/2c2df8418ac7908eec4558407b83f16739006c54 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:02 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:23 -0700 x86, acpi/irq: Introduce apci_isa_irq_to_gsi There are a number of cases where the current code makes the assumption that isa irqs identity map to the first 16 acpi global system intereupts. In most instances that assumption is correct as that is the required behaviour in dual i8259 mode and the default behavior in ioapic mode. However there are some systems out there that take advantage of acpis interrupt remapping for the isa irqs to have a completely different mapping of isa_irq to gsi. Introduce acpi_isa_irq_to_gsi to perform this mapping explicitly in the code that needs it. Initially this will be just the current assumed identity mapping to ensure it's introduction does not cause regressions. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-1-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/ia64/kernel/acpi.c | 8 ++++++++ arch/x86/kernel/acpi/boot.c | 8 ++++++++ include/linux/acpi.h | 1 + 3 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c index 4d1a7e9..c6c90f3 100644 --- a/arch/ia64/kernel/acpi.c +++ b/arch/ia64/kernel/acpi.c @@ -785,6 +785,14 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq) return 0; } +int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi) +{ + if (isa_irq >= 16) + return -1; + *gsi = isa_irq; + return 0; +} + /* * ACPI based hotplug CPU support */ diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index cd40aba..da718d6 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -458,6 +458,14 @@ ...
From: Eric W. Biederman <ebiederm@xmission.com>
In perverse acpi implementations the isa irqs are not identity mapped
to the first 16 gsi. Furthermore at least the extended interrupt
resource capability may return gsi's and not isa irqs. So since
what we get from acpi is a gsi teach acpi_get_overrride_irq to
operate on a gsi instead of an isa_irq.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/apic/io_apic.c | 23 ++++++++++++++---------
include/linux/acpi.h | 4 ++--
2 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e4e0ddc..54ba1f7 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -4073,22 +4073,27 @@ int __init io_apic_get_version(int ioapic)
return reg_01.bits.version;
}
-int acpi_get_override_irq(int bus_irq, int *trigger, int *polarity)
+int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity)
{
- int i;
+ int ioapic, pin, idx;
if (skip_ioapic_setup)
return -1;
- for (i = 0; i < mp_irq_entries; i++)
- if (mp_irqs[i].irqtype == mp_INT &&
- mp_irqs[i].srcbusirq == bus_irq)
- break;
- if (i >= mp_irq_entries)
+ ioapic = mp_find_ioapic(gsi);
+ if (ioapic < 0)
+ return -1;
+
+ pin = mp_find_ioapic_pin(ioapic, gsi);
+ if (pin < 0)
+ return -1;
+
+ idx = find_irq_entry(ioapic, pin, mp_INT);
+ if (idx < 0)
return -1;
- *trigger = irq_trigger(i);
- *polarity = irq_polarity(i);
+ *trigger = irq_trigger(idx);
+ *polarity = irq_polarity(idx);
return 0;
}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 7a937da..3da73f5 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -119,9 +119,9 @@ int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
int acpi_isa_irq_to_gsi (unsigned isa_irq, u32 *gsi);
#ifdef CONFIG_X86_IO_APIC
-extern int acpi_get_override_irq(int bus_irq, int *trigger, int *polarity);
+extern int ...Commit-ID: 9a0a91bb56d2915cdb8585717de38376ad20fef9 Gitweb: http://git.kernel.org/tip/9a0a91bb56d2915cdb8585717de38376ad20fef9 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:03 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:27 -0700 x86, acpi/irq: Teach acpi_get_override_irq to take a gsi not an isa_irq In perverse acpi implementations the isa irqs are not identity mapped to the first 16 gsi. Furthermore at least the extended interrupt resource capability may return gsi's and not isa irqs. So since what we get from acpi is a gsi teach acpi_get_overrride_irq to operate on a gsi instead of an isa_irq. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-2-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/apic/io_apic.c | 23 ++++++++++++++--------- include/linux/acpi.h | 4 ++-- 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 127b871..73ec928 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -4082,22 +4082,27 @@ int __init io_apic_get_version(int ioapic) return reg_01.bits.version; } -int acpi_get_override_irq(int bus_irq, int *trigger, int *polarity) +int acpi_get_override_irq(u32 gsi, int *trigger, int *polarity) { - int i; + int ioapic, pin, idx; if (skip_ioapic_setup) return -1; - for (i = 0; i < mp_irq_entries; i++) - if (mp_irqs[i].irqtype == mp_INT && - mp_irqs[i].srcbusirq == bus_irq) - break; - if (i >= mp_irq_entries) + ioapic = mp_find_ioapic(gsi); + if (ioapic < 0) + return -1; + + pin = mp_find_ioapic_pin(ioapic, gsi); + if (pin < 0) + return -1; + + idx = find_irq_entry(ioapic, pin, mp_INT); + if (idx < 0) return -1; - *trigger = irq_trigger(i); - *polarity = irq_polarity(i); + *trigger = ...
From: Eric W. Biederman <ebiederm@xmission.com>
Strictly speaking on x86 (where acpi is used) dev->irq must be
a dual i8259 irq input aka an isa irq. Therefore we should translate
that isa irq into a gsi before passing it to a function that
takes a gsi.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
drivers/acpi/pci_irq.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 843699e..703541d 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -400,11 +400,13 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
* driver reported one, then use it. Exit in any case.
*/
if (gsi < 0) {
+ u32 dev_gsi;
dev_warn(&dev->dev, "PCI INT %c: no GSI", pin_name(pin));
/* Interrupt Line values above 0xF are forbidden */
- if (dev->irq > 0 && (dev->irq <= 0xF)) {
- printk(" - using IRQ %d\n", dev->irq);
- acpi_register_gsi(&dev->dev, dev->irq,
+ if (dev->irq > 0 && (dev->irq <= 0xF) &&
+ (acpi_isa_irq_to_gsi(dev->irq, &dev_gsi) == 0)) {
+ printk(" - using ISA IRQ %d\n", dev->irq);
+ acpi_register_gsi(&dev->dev, dev_gsi,
ACPI_LEVEL_SENSITIVE,
ACPI_ACTIVE_LOW);
return 0;
--
1.6.5.2.143.g8cc62
--
Commit-ID: 414d3448dbcb40807a1265ace64b2576ef919fbe Gitweb: http://git.kernel.org/tip/414d3448dbcb40807a1265ace64b2576ef919fbe Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:04 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:30 -0700 x86, acpi/irq: pci device dev->irq is an isa irq not a gsi Strictly speaking on x86 (where acpi is used) dev->irq must be a dual i8259 irq input aka an isa irq. Therefore we should translate that isa irq into a gsi before passing it to a function that takes a gsi. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-3-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- drivers/acpi/pci_irq.c | 8 +++++--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c index b0a71ec..e4804fb 100644 --- a/drivers/acpi/pci_irq.c +++ b/drivers/acpi/pci_irq.c @@ -401,11 +401,13 @@ int acpi_pci_irq_enable(struct pci_dev *dev) * driver reported one, then use it. Exit in any case. */ if (gsi < 0) { + u32 dev_gsi; dev_warn(&dev->dev, "PCI INT %c: no GSI", pin_name(pin)); /* Interrupt Line values above 0xF are forbidden */ - if (dev->irq > 0 && (dev->irq <= 0xF)) { - printk(" - using IRQ %d\n", dev->irq); - acpi_register_gsi(&dev->dev, dev->irq, + if (dev->irq > 0 && (dev->irq <= 0xF) && + (acpi_isa_irq_to_gsi(dev->irq, &dev_gsi) == 0)) { + printk(" - using ISA IRQ %d\n", dev->irq); + acpi_register_gsi(&dev->dev, dev_gsi, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW); return 0; --
From: Eric W. Biederman <ebiederm@xmission.com>
This patches fixes the types of gsi_base and gsi_end values in
struct mp_ioapic_gsi, and the gsi parameter of mp_find_ioapic
and mp_find_ioapic_pin
A gsi is cannonically a u32, not an int.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/io_apic.h | 10 +++++-----
arch/x86/kernel/apic/io_apic.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 35832a0..feeaf0d 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -180,12 +180,12 @@ extern void ioapic_write_entry(int apic, int pin,
extern void setup_ioapic_ids_from_mpc(void);
struct mp_ioapic_gsi{
- int gsi_base;
- int gsi_end;
+ u32 gsi_base;
+ u32 gsi_end;
};
extern struct mp_ioapic_gsi mp_gsi_routing[];
-int mp_find_ioapic(int gsi);
-int mp_find_ioapic_pin(int ioapic, int gsi);
+int mp_find_ioapic(u32 gsi);
+int mp_find_ioapic_pin(int ioapic, u32 gsi);
void __init mp_register_ioapic(int id, u32 address, u32 gsi_base);
extern void __init pre_init_apic_IRQ0(void);
@@ -197,7 +197,7 @@ static const int timer_through_8259 = 0;
static inline void ioapic_init_mappings(void) { }
static inline void ioapic_insert_resources(void) { }
static inline void probe_nr_irqs_gsi(void) { }
-static inline int mp_find_ioapic(int gsi) { return 0; }
+static inline int mp_find_ioapic(u32 gsi) { return 0; }
struct io_apic_irq_attr;
static inline int io_apic_set_pci_routing(struct device *dev, int irq,
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 7e139bb..4611c43 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -4238,7 +4238,7 @@ void __init ioapic_insert_resources(void)
}
}
-int mp_find_ioapic(int gsi)
+int mp_find_ioapic(u32 gsi)
{
int i = 0;
@@ -4253,7 +4253,7 @@ int mp_find_ioapic(int gsi)
return -1;
}
-int ...Commit-ID: eddb0c55a14074d6bac8c2ef169aefd7e2c6f139 Gitweb: http://git.kernel.org/tip/eddb0c55a14074d6bac8c2ef169aefd7e2c6f139 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:09 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:52 -0700 x86, ioapic: Fix the types of gsi values This patches fixes the types of gsi_base and gsi_end values in struct mp_ioapic_gsi, and the gsi parameter of mp_find_ioapic and mp_find_ioapic_pin A gsi is cannonically a u32, not an int. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-8-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/io_apic.h | 10 +++++----- arch/x86/kernel/apic/io_apic.c | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h index 35832a0..feeaf0d 100644 --- a/arch/x86/include/asm/io_apic.h +++ b/arch/x86/include/asm/io_apic.h @@ -180,12 +180,12 @@ extern void ioapic_write_entry(int apic, int pin, extern void setup_ioapic_ids_from_mpc(void); struct mp_ioapic_gsi{ - int gsi_base; - int gsi_end; + u32 gsi_base; + u32 gsi_end; }; extern struct mp_ioapic_gsi mp_gsi_routing[]; -int mp_find_ioapic(int gsi); -int mp_find_ioapic_pin(int ioapic, int gsi); +int mp_find_ioapic(u32 gsi); +int mp_find_ioapic_pin(int ioapic, u32 gsi); void __init mp_register_ioapic(int id, u32 address, u32 gsi_base); extern void __init pre_init_apic_IRQ0(void); @@ -197,7 +197,7 @@ static const int timer_through_8259 = 0; static inline void ioapic_init_mappings(void) { } static inline void ioapic_insert_resources(void) { } static inline void probe_nr_irqs_gsi(void) { } -static inline int mp_find_ioapic(int gsi) { return 0; } +static inline int mp_find_ioapic(u32 gsi) { return 0; } struct io_apic_irq_attr; static inline int io_apic_set_pci_routing(struct ...
From: Eric W. Biederman <ebiederm@xmission.com>
Currently acpi_sci_ioapic_setup calls mp_override_legacy_irq with
bus_irq == gsi, which is wrong if we are comming from an override
Instead pass the bus_irq into acpi_sci_ioapic_setup.
This fix was inspired by a similar fix from:
Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/acpi/boot.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index f96060d..1742888 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -312,7 +312,7 @@ acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end)
/*
* Parse Interrupt Source Override for the ACPI SCI
*/
-static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
+static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger, u32 gsi)
{
if (trigger == 0) /* compatible SCI trigger is level */
trigger = 3;
@@ -332,7 +332,7 @@ static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger)
* If GSI is < 16, this will update its flags,
* else it will create a new mp_irqs[] entry.
*/
- mp_override_legacy_irq(gsi, polarity, trigger, gsi);
+ mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
/*
* stash over-ride to indicate we've been here
@@ -356,9 +356,10 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header * header,
acpi_table_print_madt_entry(header);
if (intsrc->source_irq == acpi_gbl_FADT.sci_interrupt) {
- acpi_sci_ioapic_setup(intsrc->global_irq,
+ acpi_sci_ioapic_setup(intsrc->source_irq,
intsrc->inti_flags & ACPI_MADT_POLARITY_MASK,
- (intsrc->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2);
+ (intsrc->inti_flags & ACPI_MADT_TRIGGER_MASK) >> 2,
+ intsrc->global_irq);
return 0;
}
@@ -1161,7 +1162,8 @@ static int __init ...Commit-ID: 9d2062b879495649bb525cf7979126da2e45d288 Gitweb: http://git.kernel.org/tip/9d2062b879495649bb525cf7979126da2e45d288 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:05 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:34 -0700 x86, acpi/irq: Fix acpi_sci_ioapic_setup so it has both bus_irq and gsi Currently acpi_sci_ioapic_setup calls mp_override_legacy_irq with bus_irq == gsi, which is wrong if we are comming from an override Instead pass the bus_irq into acpi_sci_ioapic_setup. This fix was inspired by a similar fix from: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-4-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/acpi/boot.c | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index da718d6..0a036dc 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -313,7 +313,7 @@ acpi_parse_ioapic(struct acpi_subtable_header * header, const unsigned long end) /* * Parse Interrupt Source Override for the ACPI SCI */ -static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger) +static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger, u32 gsi) { if (trigger == 0) /* compatible SCI trigger is level */ trigger = 3; @@ -333,7 +333,7 @@ static void __init acpi_sci_ioapic_setup(u32 gsi, u16 polarity, u16 trigger) * If GSI is < 16, this will update its flags, * else it will create a new mp_irqs[] entry. */ - mp_override_legacy_irq(gsi, polarity, trigger, gsi); + mp_override_legacy_irq(bus_irq, polarity, trigger, gsi); /* * stash over-ride to indicate we've been here @@ -357,9 +357,10 @@ acpi_parse_int_src_ovr(struct acpi_subtable_header * header, ...
From: Eric W. Biederman <ebiederm@xmission.com>
Multiple declarations of the same function in different headers
is a pain to maintain.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/include/asm/mpspec.h | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index d8bf23a..29994f0 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -106,10 +106,6 @@ struct device;
extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level,
int active_high_low);
extern int acpi_probe_gsi(void);
-#ifdef CONFIG_X86_IO_APIC
-extern int mp_find_ioapic(int gsi);
-extern int mp_find_ioapic_pin(int ioapic, int gsi);
-#endif
#else /* !CONFIG_ACPI: */
static inline int acpi_probe_gsi(void)
{
--
1.6.5.2.143.g8cc62
--
Commit-ID: 9638fa521e42c9281c874c6b5a382b1ced4ee496 Gitweb: http://git.kernel.org/tip/9638fa521e42c9281c874c6b5a382b1ced4ee496 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:07 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:44 -0700 x86, ioapic: Only export mp_find_ioapic and mp_find_ioapic_pin in io_apic.h Multiple declarations of the same function in different headers is a pain to maintain. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-6-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/mpspec.h | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h index d8bf23a..29994f0 100644 --- a/arch/x86/include/asm/mpspec.h +++ b/arch/x86/include/asm/mpspec.h @@ -106,10 +106,6 @@ struct device; extern int mp_register_gsi(struct device *dev, u32 gsi, int edge_level, int active_high_low); extern int acpi_probe_gsi(void); -#ifdef CONFIG_X86_IO_APIC -extern int mp_find_ioapic(int gsi); -extern int mp_find_ioapic_pin(int ioapic, int gsi); -#endif #else /* !CONFIG_ACPI: */ static inline int acpi_probe_gsi(void) { --
From: Eric W. Biederman <ebiederm@xmission.com> io_apic_redir_entries has a huge conceptual bug. It returns the maximum redirection entry not the number of redirection entries. Which simply does not match what the name of the function. This just caught me and it caught Feng Tang, and Len Brown when they wrote sfi_parse_ioapic. Modify io_apic_redir_entries to actually return the number of redirection entries, and fix the callers so that they properly handle receiving the number of the number of redirection table entries, instead of the number of redirection table entries less one. While the usage in sfi.c does not show up in this patch it is fixed by virtue of the fact that io_apic_redir_entries now has the semantics sfi_parse_ioapic most reasonably expects. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> --- arch/x86/kernel/apic/io_apic.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 54ba1f7..7e139bb 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3846,7 +3846,11 @@ int __init io_apic_get_redir_entries (int ioapic) reg_01.raw = io_apic_read(ioapic, 1); raw_spin_unlock_irqrestore(&ioapic_lock, flags); - return reg_01.bits.entries; + /* The register returns the maximum index redir index + * supported, which is one less than the total number of redir + * entries. + */ + return reg_01.bits.entries + 1; } void __init probe_nr_irqs_gsi(void) @@ -3862,7 +3866,7 @@ void __init probe_nr_irqs_gsi(void) nr = 0; for (idx = 0; idx < nr_ioapics; idx++) - nr += io_apic_get_redir_entries(idx) + 1; + nr += io_apic_get_redir_entries(idx); if (nr > nr_irqs_gsi) nr_irqs_gsi = nr; @@ -4297,7 +4301,7 @@ void __init mp_register_ioapic(int id, u32 address, u32 gsi_base) */ mp_gsi_routing[idx].gsi_base = gsi_base; mp_gsi_routing[idx].gsi_end = gsi_base + - ...
Commit-ID: 4b6b19a1c7302477653d799a53d48063dd53d555 Gitweb: http://git.kernel.org/tip/4b6b19a1c7302477653d799a53d48063dd53d555 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:08 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:48 -0700 x86, ioapic: Fix io_apic_redir_entries to return the number of entries. io_apic_redir_entries has a huge conceptual bug. It returns the maximum redirection entry not the number of redirection entries. Which simply does not match what the name of the function. This just caught me and it caught Feng Tang, and Len Brown when they wrote sfi_parse_ioapic. Modify io_apic_redir_entries to actually return the number of redirection entries, and fix the callers so that they properly handle receiving the number of the number of redirection table entries, instead of the number of redirection table entries less one. While the usage in sfi.c does not show up in this patch it is fixed by virtue of the fact that io_apic_redir_entries now has the semantics sfi_parse_ioapic most reasonably expects. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-7-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/apic/io_apic.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 73ec928..0a053e6 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -3855,7 +3855,11 @@ int __init io_apic_get_redir_entries (int ioapic) reg_01.raw = io_apic_read(ioapic, 1); raw_spin_unlock_irqrestore(&ioapic_lock, flags); - return reg_01.bits.entries; + /* The register returns the maximum index redir index + * supported, which is one less than the total number of redir + * entries. + */ + return reg_01.bits.entries + 1; } void __init probe_nr_irqs_gsi(void) @@ ...
From: Eric W. Biederman <ebiederm@xmission.com>
Long ago MP_ioapic_info was the primary way of setting up our
ioapic data structures and mp_register_ioapic was a compatibility
shim for acpi code. Now the situation is reversed and
and mp_register_ioapic is the primary way of setting up our
ioapic data structures.
Keep the setting up of ioapic data structures uniform by
having mp_register_ioapic call mp_register_ioapic.
This changes a few fields:
- type: is now hardset to MP_IOAPIC but type had to
bey MP_IOAPIC or MP_ioapic_info would not have been called.
- flags: is now hard coded to MPC_APIC_USABLE.
We require flags to contain at least MPC_APIC_USEBLE in
MP_ioapic_info and we don't ever examine flags so dropping
a few flags that might possibly exist that we have never
used is harmless.
- apicaddr: Unchanged
- apicver: Read from the ioapic instead of using the cached
hardware value in the MP table. The real hardware value
will be more accurate.
- apicid: Now verified to be unique and changed if it is not.
If the BIOS got this right this is a noop. If the BIOS did
not fixing things appears to be the better solution.
This adds gsi_base and gsi_end values to our ioapics defined with
the mpatable, which will make our lives simpler later since
we can always assume gsi_base and gsi_end are valid.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
arch/x86/kernel/mpparse.c | 25 +------------------------
1 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c
index a2c1edd..22ba4f3 100644
--- a/arch/x86/kernel/mpparse.c
+++ b/arch/x86/kernel/mpparse.c
@@ -115,21 +115,6 @@ static void __init MP_bus_info(struct mpc_bus *m)
printk(KERN_WARNING "Unknown bustype %s - ignoring\n", str);
}
-static int bad_ioapic(unsigned long address)
-{
- if (nr_ioapics >= MAX_IO_APICS) {
- printk(KERN_ERR "ERROR: Max # of I/O APICs (%d) exceeded "
- "(found %d)\n", ...Commit-ID: cf7500c0ea133d66f8449d86392d83f840102632 Gitweb: http://git.kernel.org/tip/cf7500c0ea133d66f8449d86392d83f840102632 Author: Eric W. Biederman <ebiederm@xmission.com> AuthorDate: Tue, 30 Mar 2010 01:07:11 -0700 Committer: H. Peter Anvin <hpa@zytor.com> CommitDate: Tue, 4 May 2010 13:34:59 -0700 x86, ioapic: In mpparse use mp_register_ioapic Long ago MP_ioapic_info was the primary way of setting up our ioapic data structures and mp_register_ioapic was a compatibility shim for acpi code. Now the situation is reversed and and mp_register_ioapic is the primary way of setting up our ioapic data structures. Keep the setting up of ioapic data structures uniform by having mp_register_ioapic call mp_register_ioapic. This changes a few fields: - type: is now hardset to MP_IOAPIC but type had to bey MP_IOAPIC or MP_ioapic_info would not have been called. - flags: is now hard coded to MPC_APIC_USABLE. We require flags to contain at least MPC_APIC_USEBLE in MP_ioapic_info and we don't ever examine flags so dropping a few flags that might possibly exist that we have never used is harmless. - apicaddr: Unchanged - apicver: Read from the ioapic instead of using the cached hardware value in the MP table. The real hardware value will be more accurate. - apicid: Now verified to be unique and changed if it is not. If the BIOS got this right this is a noop. If the BIOS did not fixing things appears to be the better solution. This adds gsi_base and gsi_end values to our ioapics defined with the mpatable, which will make our lives simpler later since we can always assume gsi_base and gsi_end are valid. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> LKML-Reference: <1269936436-7039-10-git-send-email-ebiederm@xmission.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/kernel/mpparse.c | 25 +------------------------ 1 files changed, 1 insertions(+), 24 deletions(-) diff --git a/arch/x86/kernel/mpparse.c ...
ping Where are we at with this patchset? Eric --
You might run into trouble here on the ES7000 -- though I don't know if anybody is booting a modern kernel on one of those these days. IIR, ES7000 treated the bottom 16 as a special case. When there was an irq shortage, I think they used overrides to map higher PCI irqs into the empty spots below 16, but I think to make room for them they may have mapped some of the ISA irqs to high numbers. Fuzzy memory on this at the moment... cheers, Len Brown, Intel Open Source Technology Center --
A couple of things. The ES7000 change is trivially safe because despite differences in how the numbers are computed I have made that transform that the es7000 does always apply. I also talked to Natalie about this. I can't be certain about this but from your description, from Natalies memories and from looking at the code. I believe the problem on the ES7000 is exactly what I am fixing in the code. Natalie has threatened to test this on an ES7000. The case of interest is this: Weird but valid platforms where GSI 0-15 are not ISA irqs. Some high numbered GSIs are ISA irqs and use interrupt source overrides to describe them. That is the case on the IBM platform that regressed a bit ago and Iranna D Ankad bisected a failure on. On that IBM platform GSI 0-15 (because the are not ISA irqs) are unusable today. Everything points to this problem I an fixing being the problem with early ES7000 machines, including the memory of their boot firmware developers complaint that they were in spec. Eric --
Eric pointed out that radix tree version of irq_to_desc will magnify delay on
the path of handle_irq.
use vector_desc to reduce the calling of irq_to_desc.
next step: need to change all ack, mask, umask, eoi for all irq_chip to take irq_desc
-v2: irq should be unsigned in 32bit handle_irq according to Eric
also reset vector_desc for lguest in setup_irq
-v3: keep irq in x+execute_on_irq_stack() ...
-v4: update after legacy_pic
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
arch/x86/include/asm/desc.h | 2 +-
arch/x86/include/asm/hw_irq.h | 13 ++++---
arch/x86/include/asm/irq.h | 3 +-
arch/x86/kernel/apic/io_apic.c | 77 +++++++++++++++++++++-------------------
arch/x86/kernel/irq.c | 15 ++++----
arch/x86/kernel/irq_32.c | 13 ++++---
arch/x86/kernel/irq_64.c | 7 +---
arch/x86/kernel/irqinit.c | 14 +++----
arch/x86/kernel/smpboot.c | 2 +-
arch/x86/kernel/uv_irq.c | 2 +-
arch/x86/kernel/vmiclock_32.c | 2 +-
arch/x86/lguest/boot.c | 7 +++-
12 files changed, 82 insertions(+), 75 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index 617bd56..25c5635 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -334,7 +334,7 @@ static inline void set_intr_gate(unsigned int n, void *addr)
}
extern int first_system_vector;
-/* used_vectors is BITMAP for irq is not managed by percpu vector_irq */
+/* used_vectors is BITMAP for irq is not managed by percpu vector_desc */
extern unsigned long used_vectors[];
static inline void alloc_system_vector(int vector)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 767d3f8..d23cf94 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -97,7 +97,8 @@ struct irq_cfg {
};
extern struct irq_cfg *irq_cfg(unsigned int);
-extern int assign_irq_vector(int, ...__clear_irq_vector(desc, desc->chip_data); That printk is confusing. It's not lacking an irq handler. The vector is simply not assigned. Thanks, tglx --
Well at least originally DECLARE_PER_CPU chocked when given a complex type. Does: DECLARE_PER_CPU(struct irq_desc *[NR_VECTORS], vector_desc); Long evolution. Do you have a suggestion of better wording? Eric --
I really have a hard time to see how assigning a void pointer to a
struct irq_cfg pointer is anymore type safe than using the void
You mean hysterical raisins. Ok, how about:
pr_emerg("irq: %d.d irq vector not assigned\n", ...);
Thanks,
tglx
--
From: Ian Campbell <ian.campbell@citrix.com>
Move arch_init_copy_chip_data and arch_free_chip_data into function
pointers in struct irq_chip since they operate on irq_desc->chip_data.
arch_init_chip_data cannot be moved into struct irq_chip because
irq_desc->chip is not known at the time the irq_desc is setup. Instead
rename arch_init_chip_data to arch_init_irq_desc for PowerPC, the
only other user, whose usage better matches the new name.
To replace the x86 arch_init_chip_data functionality
irq_to_desc_alloc_node now takes a pointer to a function to allocate
the chip data. This is necessary to ensure the allocation happens
under the correct locking at the core level. On PowerPC and SH
architectures (the other users of irq_to_desc_alloc_node) pass in NULL
which retains existing chip_data behaviour.
I've retained the chip_data behaviour for uv_irq although it isn't
clear to me if these interrupt types support migration or how closely
related to the APIC modes they really are. If it weren't for this the
x86_{init,copy,free}_chip_data functions could be static to
io_apic.c.
I've tested by booting on an 64 bit x86 system with sparse IRQ enabled
and 32 bit without, but it's not clear to me what actions I need to
take to actually exercise some of these code paths.
-v4: yinghai add irq_to_desc_alloc_node_x...
so could leave default path not changed...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Michael Ellerman <michael@ellerman.id.au> [PowerPC rename portion]
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: x86@kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: lguest@ozlabs.org
Cc: Paul Mundt ...This is a bit feral, that is the init_chip_data_fn. Which is really just a hack to avoid an if (xen) check isn't it? It looks to me like this should just be done via a current machine vector or platform routine, in the same way as powerpc and (I think) cheers
arch/powerpc/kernel/irq.c | 2 +-
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..cafd378 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
return 0;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int arch_init_irq_desc(struct irq_desc *desc, int node, init_chip_data_fn fn)
{
desc->status |= IRQ_NOREQUEST;
return 0;
looks like xen in same run time, some irqs need x86_init_chip_data,
and some may need xen_init_chip_data later.
Thanks
Yinghai
--
This API seems to be going from bad to worse. Initially we had arch_init_chip_data(), which had precisely nothing to do with chip_data and only concerned itself with irq_desc, and now you're renaming it to something sensible but also trying to bolt on some ad-hoc chip_data relation at the same time thereby nullifying any benefit obtained from renaming the function in the first place. Renaming to xxx_irq_desc() while preserving the existing prototypes would I'm afraid I am unable to grasp the meaning of this sentence, or what precisely this has to do with not being able to utilize platform ops to get this sorted out on x86. You're effectively trying to have the hardirq code pass around a function pointer for you that ultimately only serves to bail out on certain code paths if you're running under xen, which is a concern for how the platform chooses to initialize the irq desc, none of this has any value or relevance to the hardirq code outside of that. The fact that the hardirq code doesn't do anything with this information other than pass it around for your platform should already be a clear indicator that this is the wrong way to go. From a cursory look at the x86 code, this looks like precisely the sort of thing that arch/x86/include/asm/x86_init.h is well suited for, and indeed you already have a x86_init_irqs to expand on as needed. The function pointer thing itself is also a bit unorthodox to say the least. You're introducing and passing around an opaque type just so you can get to a 'return 0' in the xen case as far as I can tell, so you could also just make arch_init_chip_data() a weak symbol and clobber it in the xen case, no? --
The ultimate aim is to have Xen use the chip data to store the event channel information relating to each IRQ instead of keeping it in a static NR_IRQs array, the new function only returns 0 as a placeholder until this can be put in place (which depends on these changes), it could as well have been left out for the time being (e.g. passing NULL A single kernel is able to boot native or Xen so a weak symbol doesn't really work, having the function pointer at the arch level is one similar option, I've replied to Thomas' similar suggestion. Ian. --
Not sure about that. These functions are solely used by x86 and there is really no need to generalize them. The problem you try to solve is x86/xen specific and can be solved by x86_platform_ops as well w/o Err, that argument is totally bogus. The calling convention of irq_to_desc_alloc_node and arch_init_chip_data/arch_init_irq_desc is still the same. It does not explain why the heck we need that function pointer at all. AFAICT the function pointer to irq_to_desc_alloc_node is completely pointless. It just solves a Xen/x86 specific problem which can be Aside of the general objection against this, please use descriptive function names and do not distinguish functions by adding random characters which tell us absolutely nothing about the purpose. Thanks, tglx --
I thought the idea of struct irq_chip was to allow the potential for multiple IRQ controllers in a system? Given that it seems that struct irq_desc->chip_data ought to be available for use by whichever struct irq_chip is managing a given interrupt. At the moment this is not possible because we step around the abstraction using these arch_* methods. Although this might be unusual on x86 I think it is not uncommon in the embedded world to have an architectural interrupt controller cascading through to various different IRQ controllers/multiplexors, from random FPGA based things, to GPIO controllers and things like superio chips etc. Currently the set of architectures which typically have this sort of thing are disjoint from the ones which make use of struct irq_desc->chip_data but with the growing use of embedded-x86 is this not something worth considering? (Genuine question, I've been out of the embedded space for a while now so maybe my experiences are out of date or I'm overestimating the role of embedded-x86 etc). Xen is a bit more of a specialised case than the above since it would like to replace the architectural interrupt handling but I think the broad requirements on the irq_chip interface are the same. Going forward it is possible/likely that we would like to be able to make Xen event channels available via a cascade model as well -- demultiplexing one (or more?) x86 architectural interrupts into event channels would be part of I have no problem with that if that is the x86/irq maintainer's preference, I just thought it would be nicer to solve what I saw as an I agree on this one. More generally I would say that the number of existing users of this interface is small enough that _if_ we decide we need to modify it then we should just bite the bullet and do that instead of building compatibility layers around stuff. For this reason I think my original patch was preferable to this version (general objections not withstanding). Ian. --
Right, but you have exactly _ONE_ irq_chip associated to an irq_desc, but that same irq_chip can be associated to several irq_descs. So irq_desc->data is there to provide data for the irq_chip functions depending on what irq they handle (e.g. base_address ...). irq_desc->chip_data is set when the irq_chip is assigned to the irq_desc. So there is no point in having functions in irq_chip to set irq_desc->chip_data. Thanks, tglx --
So how do you know which is the appropriate irq_chip specific function to call given an irq_desc that you want to copy/free/migrate? The contents of the chip_data pointer will take different forms for different irq_chips. The way the generic code is currently structured it appears you can't (or at least don't) just do a shallow copy by copying the irq_desc->chip_data pointer itself -- you need to do a deep copy using a function which understands that type of chip_data. How is this operation different to having pointers in irq_chip for enabling/disabling/masking interrupts for each irq_chip? Ian. --
The design of sparse_irq or to be honest the lack of design grew that
crap and it's not only this detail which is a nightmare. That pointer
should probably be simply copied. Either that or if the chip data
require to be node bound we need something along the line:
struct sparse_irq_chip_data {
void *data;
void (*copy)(...);
void (*free)(...);
};
and a corresponding field in irq_desc.
I'm looking into sparse_irq right now anyway because it has other way
Because that's the purpose of the irq_chip perhaps ?
Thanks,
tglx
--
