From: Kai G. <ka...@tp...> - 2002-01-15 08:50:20
|
Hi! Time to summarize some of the experiences with ACPI PCI IRQ routing. o The latest ACPI release (20011218, is this still the latest?) includes some changes to handle disabled LNKx devices. I think we should just report the IRQ as not routed in acpi_get_link_irq() if the devices is not present or not decoding resources. The current code enables the device in this case by calling _CRS and the _SRS. I'm not even sure if _CRS is supposed to work correctly when the device is disabled. But in any case, acpi_get_link_irq() is called during early PCI init. I believe there is a reason why we try to read current settings only, but don't change anything. ({pci,acpi}_lookup_irq() is called with assign = 0, to avoid fiddling with the hardware which is not necessary at this point. So we should continue on the safe path and have acpi_get_link_irq() fail if the device is enabled. Only later, when we pci_enable_device(), we need the IRQ line to be routed, so at that point we call acpi_set_link_irq(), which will actually setup the IRQ routing. o Handling of PCI buses / bridges. I've looked at different DSDTs, and of course (they're from the BIOS, after all), they're not consistent. Sometimes all buses have _PRT entries, sometimes only the root bus. I believe we should try to find a matching _PRT entry first, if not we should assume the standard IRQ mapping on the bridge and use the _PRT entry for the bridge (which hopefully exists). - similar to pci_get_interrupt_pin() in drivers/pci/pci.c. I haven't done that yet. o I had some testing reports (which boiled down to one specific notebook) where my initial ACPI IRQ routing patch didn't work (the standard PCI IRQ routing code doesn't work either, though). The routing did work when assigning the IRQ was forced on (currently we do so only if _CRS reports no IRQ). It turned out then, that it was not the _SRS call, though, but the eisa_set_level(). So we need to call eisa_set_level() unconditionally in acpi_lookup_irq() when assign==1, it's an open question if we should call acpi_pci_set_current_irq()/_SRS unconditionally (I do so currently) The appended patch is my current diff, which works on every ACPI machine I've tested so far, which isn't all that many (440BX based desktop / laptop, VIA KT133, i810, some VIA based notebooks). You have to add "pci=acpiirq" to the kernel command line to have ACPI IRQ routing used instead of the standard IRQ routing code. Test reports are more than welcome ;-) --Kai diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-i386.h linux-2.4.17.work/arch/i386/kernel/pci-i386.h --- linux-2.4.17.patches/arch/i386/kernel/pci-i386.h Mon Jan 14 23:55:08 2002 +++ linux-2.4.17.work/arch/i386/kernel/pci-i386.h Fri Dec 28 23:19:14 2001 @@ -21,6 +21,7 @@ #define PCI_ASSIGN_ROMS 0x1000 #define PCI_BIOS_IRQ_SCAN 0x2000 #define PCI_ASSIGN_ALL_BUSSES 0x4000 +#define PCI_ACPI_IRQ 0x8000 extern unsigned int pci_probe; diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-irq.c linux-2.4.17.work/arch/i386/kernel/pci-irq.c --- linux-2.4.17.patches/arch/i386/kernel/pci-irq.c Mon Jan 14 23:55:08 2002 +++ linux-2.4.17.work/arch/i386/kernel/pci-irq.c Tue Jan 8 00:01:32 2002 @@ -512,6 +512,82 @@ pirq_router_dev->slot_name); } +static void pcibios_test_irq_handler(int irq, void *dev_id, struct pt_regs *regs) +{ +} + +#ifdef CONFIG_ACPI_PCI + +extern int acpi_pci_get_current_irq(struct pci_dev *dev, u8 pin, int *irq); +extern int acpi_pci_set_current_irq(struct pci_dev *dev, u8 pin, int irq); +extern int acpi_pci_get_possible_irq_mask(struct pci_dev *dev, u8 pin, int *mask); + +static int acpi_lookup_irq(struct pci_dev *dev, u8 pin, int assign) +{ + int newirq, i, irq, retval; + char *msg = NULL; + u32 mask; + + DBG("IRQ for %s:%d (%d)", dev->slot_name, pin, dev->irq); + + retval = acpi_pci_get_current_irq(dev, pin, &irq); + if (retval < 0) { + DBG(" -> failed\n"); + return 0; + } + DBG(" -> irq %d", irq); + + retval = acpi_pci_get_possible_irq_mask(dev, pin, &mask); + if (retval < 0) { + DBG(" -> failed\n"); + return 0; + } + DBG(" -> mask %04x", mask); + mask &= pcibios_irq_mask; + + + if (assign) { + /* Find the best IRQ to assign */ + newirq = 0; + for (i = 0; i < 16; i++) { + if (!(mask & (1 << i))) + continue; + if (pirq_penalty[i] < pirq_penalty[newirq] && + !request_irq(i, pcibios_test_irq_handler, SA_SHIRQ, "pci-test", dev)) { + free_irq(i, dev); + newirq = i; + } + } + /* Use the current IRQ if possible */ + if (irq && ((1 << irq) & mask)) + newirq = irq; + + DBG(" -> newirq=%d", newirq); + if (newirq && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) { + DBG(" -> assigning IRQ %d", newirq); + if (acpi_pci_set_current_irq(dev, pin, newirq) == 0) { + eisa_set_level_irq(newirq); + DBG(" ... OK\n"); + msg = "Assigned"; + irq = newirq; + } + } + } else { + msg = "Found"; + } + + if (irq) { + printk(KERN_INFO "PCI: %s IRQ %d for device %s\n", msg, irq, dev->slot_name); + + dev->irq = irq; + pirq_penalty[irq]++; + return 1; + } + return 0; +} + +#endif + static struct irq_info *pirq_get_info(struct pci_dev *dev) { struct irq_routing_table *rt = pirq_table; @@ -524,38 +600,25 @@ return NULL; } -static void pcibios_test_irq_handler(int irq, void *dev_id, struct pt_regs *regs) -{ -} - -static int pcibios_lookup_irq(struct pci_dev *dev, int assign) +static int pirq_lookup_irq(struct pci_dev *dev, u8 pin, int assign) { - u8 pin; - struct irq_info *info; - int i, pirq, newirq; - int irq = 0; - u32 mask; struct irq_router *r = pirq_router; + struct irq_info *info; + int newirq, pirq, i, irq = 0; struct pci_dev *dev2; char *msg = NULL; + u32 mask; if (!pirq_table) return 0; - /* Find IRQ routing entry */ - pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); - if (!pin) { - DBG(" -> no interrupt pin\n"); - return 0; - } - pin = pin - 1; - DBG("IRQ for %s:%d", dev->slot_name, pin); info = pirq_get_info(dev); if (!info) { DBG(" -> not found in routing table\n"); return 0; } + pirq = info->irq[pin].link; mask = info->irq[pin].bitmap; if (!pirq) { @@ -636,26 +699,47 @@ return 1; } +static int pcibios_lookup_irq(struct pci_dev *dev, int assign) +{ + u8 pin; + + /* Find IRQ routing entry */ + pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); + if (!pin) { + DBG("PCI: %s: no interrupt pin\n", dev->slot_name); + return 0; + } + pin -= 1; + +#ifdef CONFIG_ACPI_PCI + if (pci_probe & PCI_ACPI_IRQ) + return acpi_lookup_irq(dev, pin, assign); +#endif + return pirq_lookup_irq(dev, pin, assign); +} + void __init pcibios_irq_init(void) { DBG("PCI: IRQ init\n"); - pirq_table = pirq_find_routing_table(); + if (!(pci_probe & PCI_ACPI_IRQ)) { + pirq_table = pirq_find_routing_table(); #ifdef CONFIG_PCI_BIOS - if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) - pirq_table = pcibios_get_irq_routing_table(); + if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) + pirq_table = pcibios_get_irq_routing_table(); #endif - if (pirq_table) { - pirq_peer_trick(); - pirq_find_router(); - if (pirq_table->exclusive_irqs) { - int i; - for (i=0; i<16; i++) - if (!(pirq_table->exclusive_irqs & (1 << i))) - pirq_penalty[i] += 100; - } - /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ - if (io_apic_assign_pci_irqs) - pirq_table = NULL; + if (pirq_table) { + pirq_peer_trick(); + pirq_find_router(); + if (pirq_table->exclusive_irqs) { + int i; + for (i=0; i<16; i++) + if (!(pirq_table->exclusive_irqs & (1 << i))) + pirq_penalty[i] += 100; + } + /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ + if (io_apic_assign_pci_irqs) + pirq_table = NULL; + } } } diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-pc.c linux-2.4.17.work/arch/i386/kernel/pci-pc.c --- linux-2.4.17.patches/arch/i386/kernel/pci-pc.c Mon Jan 14 23:55:08 2002 +++ linux-2.4.17.work/arch/i386/kernel/pci-pc.c Fri Dec 28 23:18:54 2001 @@ -1253,6 +1253,12 @@ return NULL; } #endif +#ifdef CONFIG_ACPI_PCI + else if (!strcmp(str, "acpiirq")) { + pci_probe |= PCI_ACPI_IRQ; + return NULL; + } +#endif #ifdef CONFIG_PCI_DIRECT else if (!strcmp(str, "conf1")) { pci_probe = PCI_PROBE_CONF1 | PCI_NO_CHECKS; diff -X excl -urN linux-2.4.17.patches/drivers/acpi/acpi_pci.c linux-2.4.17.work/drivers/acpi/acpi_pci.c --- linux-2.4.17.patches/drivers/acpi/acpi_pci.c Mon Jan 14 23:55:08 2002 +++ linux-2.4.17.work/drivers/acpi/acpi_pci.c Mon Jan 7 23:22:46 2002 @@ -119,9 +119,10 @@ if ((0 != acpi_pci_get_status(handle, &sta)) || !(sta & 0x01)) return -ENODEV; -#ifdef CONFIG_ACPI_DEBUG - printk(KERN_INFO " link device currently %s\n", (sta & 0x02)?"enabled":"disabled"); -#endif + /* If disabled, return */ + + if (!(sta & 0x02)) + return 0; /* Get the current (default) IRQ assignment */ @@ -146,41 +147,167 @@ while (resource && (bytes_unparsed > 0)) { - if (index != i++) - continue; + switch (resource->id) { + case ACPI_RSTYPE_START_DPF: + case ACPI_RSTYPE_END_DPF: + break; + default: + i++; + } + + if (i <= index) + goto next; switch (resource->id) { case ACPI_RSTYPE_IRQ: - (*irq) = resource->data.irq.interrupts[0]; + { + acpi_resource_irq *p = &resource->data.irq; + + if (p->number_of_interrupts > 0) { + (*irq) = p->interrupts[0]; + } break; + } case ACPI_RSTYPE_EXT_IRQ: - (*irq) = resource->data.irq.interrupts[0]; + { + acpi_resource_ext_irq *p = &resource->data.extended_irq; + if (p->number_of_interrupts > 0) { + (*irq) = p->interrupts[0]; + } break; } + } if (*irq) break; + next: bytes_unparsed = bytes_unparsed - resource->length; if (bytes_unparsed > 0) resource = (acpi_resource*)((u8*)resource + resource->length); } - if (!(*irq)) + return 0; +} + + +static int +acpi_pci_get_link_irq_mask ( + acpi_handle handle, + u32 index, + u32 *mask) +{ + acpi_status status = AE_OK; + acpi_buffer buffer = {0, NULL}; + acpi_resource *resource = NULL; + int bytes_unparsed = 0; + int i = 0; + + if (!handle || !mask) + return -EINVAL; + + status = acpi_get_possible_resources(handle, &buffer); + if (status != AE_BUFFER_OVERFLOW) return -ENODEV; - /* If disabled, enable by evaluating _SRS using default IRQ */ + buffer.pointer = kmalloc(buffer.length, GFP_KERNEL); + if (!buffer.pointer) + return -ENOMEM; + memset(buffer.pointer, 0, buffer.length); - if (!(sta & 0x02)) { - acpi_buffer buffer = {resource->length, resource}; - printk(KERN_INFO PREFIX "Enabling _PRT entry\n"); - status = acpi_set_current_resources(handle, &buffer); - if (ACPI_FAILURE(status)) { - printk(KERN_WARNING PREFIX "Error evaluating _SRS, %s\n", - acpi_format_exception(status)); - return -ENODEV; + status = acpi_get_possible_resources(handle, &buffer); + if (ACPI_FAILURE(status)) { + kfree(buffer.pointer); + return -ENODEV; + } + + resource = (acpi_resource *) buffer.pointer; + + bytes_unparsed = buffer.length - 16; + + while (resource && (bytes_unparsed > 0)) { + + switch (resource->id) { + case ACPI_RSTYPE_START_DPF: + case ACPI_RSTYPE_END_DPF: + break; + default: + i++; + } + + if (i <= index) + goto next; + + switch (resource->id) { + case ACPI_RSTYPE_IRQ: + { + acpi_resource_irq *p = &resource->data.irq; + int j; + + *mask = 0; + for (j = 0; j < p->number_of_interrupts; j++) { + (*mask) |= (1 << p->interrupts[j]); + } + return 0; } + case ACPI_RSTYPE_EXT_IRQ: + { + acpi_resource_ext_irq *p = &resource->data.extended_irq; + int j; + + *mask = 0; + for (j = 0; j < p->number_of_interrupts; j++) { + (*mask) |= (1 << p->interrupts[j]); + } + return 0; + } + } + + next: + bytes_unparsed = bytes_unparsed - resource->length; + if (bytes_unparsed > 0) + resource = (acpi_resource *)((u8 *)resource + resource->length); } + + return -ENODEV; +} + + +static int +acpi_pci_set_link_irq ( + acpi_handle handle, + u32 index, + u32 irq) +{ + acpi_status status = AE_OK; + acpi_buffer buffer = {0, NULL}; + struct { + acpi_resource res; + acpi_resource end; + } resource; + int bytes_unparsed = 0; + int i = 0; + + + if (!handle) + return -EINVAL; + + memset(&resource, 0, sizeof(resource)); + resource.res.id = ACPI_RSTYPE_IRQ; + resource.res.length = sizeof(acpi_resource); + resource.res.data.irq.edge_level = 0; // FIXME? + resource.res.data.irq.active_high_low = 0; + resource.res.data.irq.shared_exclusive = 1; + resource.res.data.irq.number_of_interrupts = 1; + resource.res.data.irq.interrupts[0] = irq; + resource.end.id = ACPI_RSTYPE_END_TAG; + + buffer.pointer = &resource; + buffer.length = resource.res.length + 1; + status = acpi_set_current_resources(handle, &buffer); + + if (status != AE_OK) + return -ENODEV; return 0; } @@ -243,17 +370,15 @@ /* Type 1 (dynamic)? */ if (prt->source) { - acpi_handle link_handle = NULL; - acpi_get_handle(handle, prt->source, &link_handle); - acpi_pci_get_link_irq(link_handle, prt->source_index, - &prt->source_index); - prt->source[0] = 0; + prt->link_handle = NULL; + acpi_get_handle(handle, prt->source, &prt->link_handle); +/* prt->source[0] = 0; */ } #ifdef CONFIG_ACPI_DEBUG - printk(KERN_INFO " device=%02x pin=%02x irq=%d\n", + printk(KERN_INFO " device=%02x pin=%02x source=%s source_index=%d\n", (u32)(prt->address>>16), (u32)prt->pin, - (u32)prt->source_index); + prt->source, (u32)prt->source_index); #endif /*CONFIG_ACPI_DEBUG*/ acpi_prt.count++; @@ -266,6 +391,92 @@ } +static acpi_pci_routing_table * +acpi_pci_find_routing_table_entry(struct pci_dev *dev, u8 pin) +{ + int busnr = dev->bus->number; + acpi_pci_routing_table *prt = NULL; + + if (busnr >= ACPI_PCI_MAX_BUS) + return 0; + + prt = (acpi_pci_routing_table *) acpi_prt.entry[busnr]; + while (prt && prt->length > 0) { + if ((prt->address >> 16) == PCI_SLOT(dev->devfn) && prt->pin == pin) + return prt; + prt = (acpi_pci_routing_table *) + ((u8 *) prt + prt->length); + } + return prt; +} + + +int +acpi_pci_get_current_irq(struct pci_dev *dev, u8 pin, int *irq) +{ + acpi_pci_routing_table *prt; + + *irq = 0; + + prt = acpi_pci_find_routing_table_entry(dev, pin); + if (!prt) + return -ENODEV; + + /* Type 1 (dynamic)? */ + if (prt->source) { + return acpi_pci_get_link_irq(prt->link_handle, + prt->source_index, irq); + } else { + *irq = prt->source_index; + return 0; + } +} + + +int +acpi_pci_get_possible_irq_mask(struct pci_dev *dev, u8 pin, int *mask) +{ + acpi_pci_routing_table *prt; + + *mask = 0; + + prt = acpi_pci_find_routing_table_entry(dev, pin); + if (!prt) + return -ENODEV; + + /* Type 1 (dynamic)? */ + if (prt->source) { + return acpi_pci_get_link_irq_mask(prt->link_handle, + prt->source_index, mask); + } else { + *mask = 1 << prt->source_index; + return 0; + } +} + + +int +acpi_pci_set_current_irq(struct pci_dev *dev, u8 pin, int irq) +{ + acpi_pci_routing_table *prt; + + prt = acpi_pci_find_routing_table_entry(dev, pin); + if (!prt) + return -ENODEV; + + /* Type 1 (dynamic)? */ + if (prt->source) { + return acpi_pci_set_link_irq(prt->link_handle, + prt->source_index, irq); + } else { + if (irq != prt->source_index) + return -ENODEV; + + return 0; + } +} + + static acpi_status __init acpi_pci_resolve_bus ( acpi_handle handle, @@ -432,5 +643,3 @@ return 0; } - - diff -X excl -urN linux-2.4.17.patches/drivers/acpi/include/actypes.h linux-2.4.17.work/drivers/acpi/include/actypes.h --- linux-2.4.17.patches/drivers/acpi/include/actypes.h Mon Jan 14 23:55:08 2002 +++ linux-2.4.17.work/drivers/acpi/include/actypes.h Fri Dec 28 23:16:25 2001 @@ -1125,6 +1125,7 @@ u32 pin; acpi_integer address; /* here for 64-bit alignment */ u32 source_index; + void *link_handle; NATIVE_CHAR source[4]; /* pad to 64 bits so sizeof() works in all cases */ } acpi_pci_routing_table; |
From: Chris L. <qu...@wa...> - 2002-01-15 16:00:27
|
On Jan 15, Kai Germaschewski wrote: > The appended patch is my current diff, which works on every ACPI machine > I've tested so far, which isn't all that many (440BX based desktop / > laptop, VIA KT133, i810, some VIA based notebooks). You have to add > "pci=acpiirq" to the kernel command line to have ACPI IRQ routing used > instead of the standard IRQ routing code. > > Test reports are more than welcome ;-) It hangs on boot on a Toshiba S504-5005 laptop. I've added some extra debugging and it appears to hang when allocating an IRQ for the AC'97 Modem Controller (I think this done by the serial driver, as it is just after the serial message). The actual hang occurs in setup_irq() in arch/i386/kernel/irq.c when it calls spin_unlock_irqrestore(); it hangs on the first IRQ scanned in the /* Find the best IRQ to assign */ loop. Disabling the serial driver just moves the hang later in the boot sequence (to the Ethernet controller). The code appears to start the IRQ scan at IRQ 7 for both devices. Other IRQs seem to be setup OK for non-PCI devices like the RTC, and if I boot with acpi=off, the system will boot (minus IRQ assignments for non-boot devices, even with pci=acpiirq specified), so I dunno if there's something weird going on with the spinlock code or what. Chris -- Chris Lawrence <ch...@lo...> - http://www.lordsutch.com/chris/ |
From: Kai G. <ka...@tp...> - 2002-01-17 15:41:57
|
On Tue, 15 Jan 2002, Chris Lawrence wrote: > It hangs on boot on a Toshiba S504-5005 laptop. I've added some extra > debugging and it appears to hang when allocating an IRQ for the AC'97 > Modem Controller (I think this done by the serial driver, as it is > just after the serial message). The actual hang occurs in setup_irq() > in arch/i386/kernel/irq.c when it calls spin_unlock_irqrestore(); it > hangs on the first IRQ scanned in the /* Find the best IRQ to assign */ > loop. You mean acpi_lookup_irq() -> request_irq() -> setup_irq()? What's the value of i in request_irq()? > Disabling the serial driver just moves the hang later in the boot > sequence (to the Ethernet controller). The code appears to start the > IRQ scan at IRQ 7 for both devices. so i == 7 above? What's the debugging output before the hang? (#define DEBUG in pci-i386.h) > Other IRQs seem to be setup OK for non-PCI devices like the RTC, and > if I boot with acpi=off, the system will boot (minus IRQ assignments > for non-boot devices, even with pci=acpiirq specified), so I dunno if > there's something weird going on with the spinlock code or what. Do you have an UP or SMP kernel? Anyway, there's no reason why setup_irq() would break, weird... BTW, what does lspci -vt say for your laptop? Does it boot if you replace "if (assign)" with "if (0)". If so, could you mail me your dmesg after boot, with ACPI debug on (kernelconfig option) and #define DEBUG in pci-i386.h, as mentioned above. --Kai |
From: Chris L. <qu...@wa...> - 2002-01-21 19:31:02
|
On Jan 17, Kai Germaschewski wrote: > On Tue, 15 Jan 2002, Chris Lawrence wrote: > > > It hangs on boot on a Toshiba S504-5005 laptop. I've added some extra > > debugging and it appears to hang when allocating an IRQ for the AC'97 > > Modem Controller (I think this done by the serial driver, as it is > > just after the serial message). The actual hang occurs in setup_irq() > > in arch/i386/kernel/irq.c when it calls spin_unlock_irqrestore(); it > > hangs on the first IRQ scanned in the /* Find the best IRQ to assign */ > > loop. > > You mean acpi_lookup_irq() -> request_irq() -> setup_irq()? What's the > value of i in request_irq()? > > > Disabling the serial driver just moves the hang later in the boot > > sequence (to the Ethernet controller). The code appears to start the > > IRQ scan at IRQ 7 for both devices. > > so i == 7 above? What's the debugging output before the hang? (#define > DEBUG in pci-i386.h) (This is with the serial driver disabled.) IRQ for 02:08.0:0 (6) -> irq 6 -> mask 0480 > > Other IRQs seem to be setup OK for non-PCI devices like the RTC, and > > if I boot with acpi=off, the system will boot (minus IRQ assignments > > for non-boot devices, even with pci=acpiirq specified), so I dunno if > > there's something weird going on with the spinlock code or what. > > Do you have an UP or SMP kernel? Anyway, there's no reason why > setup_irq() would break, weird... BTW, what does lspci -vt say for your > laptop? Does it boot if you replace "if (assign)" with "if (0)". If so, > could you mail me your dmesg after boot, with ACPI debug on (kernelconfig > option) and #define DEBUG in pci-i386.h, as mentioned above. It is a UP kernel. lspci -vt says: -[00]-+-00.0 Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub +-01.0-[01]----00.0 nVidia Corporation GeForce2 Go +-1e.0-[02-04]--+-07.0 Texas Instruments: Unknown device 8023 | +-08.0 Intel Corp. 82820 (ICH2) Chipset Ethernet Controller | +-0b.0 Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support | +-0b.1 Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support | +-0c.0 Toshiba America Info Systems: Unknown device 0804 | \-0d.0 Toshiba America Info Systems: Unknown device 0805 +-1f.0 Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) +-1f.1 Intel Corp. 82820 820 (Camino 2) Chipset IDE U100 +-1f.2 Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub A) +-1f.4 Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub B) +-1f.5 Intel Corp. 82820 820 (Camino 2) Chipset AC'97 Audio Controller \-1f.6 Intel Corp. 82820 820 (Camino 2) Chipset AC'97 Modem Controller The hang itself may have something to do with the acpi_ev_gpe_dispatch problem others have reported on this particular laptop; I haven't tried backing out the changes to that routine yet. I agree there's nothing in the setup_irq() code that should hang the system, especially since my debugging code shows it being called several times earlier without hanging. I may also try a SMP kernel to see if that makes a difference. Shouldn't (although it would change the spin_unlock_irqrestore function), but you never know. Chris -- Chris Lawrence <ch...@lo...> - http://www.lordsutch.com/chris/ |
From: <ti...@ja...> - 2002-01-15 22:08:48
|
On Tue, 15 Jan 2002, Kai Germaschewski wrote: > The appended patch is my current diff, which works on every ACPI machine > I've tested so far, which isn't all that many (440BX based desktop / > laptop, VIA KT133, i810, some VIA based notebooks). You have to add > "pci=acpiirq" to the kernel command line to have ACPI IRQ routing used > instead of the standard IRQ routing code. > > Test reports are more than welcome ;-) > > --Kai It'd doesn't do anything on a Toshiba 5005-S504. I compiled with all ACPI junk enabled, and with a GPE unfuck that was creating lockups and oom() during IDE bus scan. When booting with append = "acpi_boot=on pci=acpiirq" nothing special happens. As in, cardbus bridge still has no IRQ, nor sound or ieee1394 etc. tim -- ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・ timecop at japan.co.jp | OA通信サービス株式会社 | NTT DoCoMo Please don't CC me on anything sent to mailing lists or send me email directly unless it's a privacy issue, thanks. ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・ |
From: Kai G. <ka...@tp...> - 2002-01-17 15:41:30
|
On Wed, 16 Jan 2002 ti...@ja... wrote: > On Tue, 15 Jan 2002, Kai Germaschewski wrote: > > > The appended patch is my current diff, which works on every ACPI machine > > I've tested so far, which isn't all that many (440BX based desktop / > > laptop, VIA KT133, i810, some VIA based notebooks). You have to add > > "pci=acpiirq" to the kernel command line to have ACPI IRQ routing used > > instead of the standard IRQ routing code. > > > > Test reports are more than welcome ;-) > > > > --Kai > > It'd doesn't do anything on a Toshiba 5005-S504. I compiled with all ACPI > junk enabled, and with a GPE unfuck that was creating lockups and oom() > during IDE bus scan. When booting with > append = "acpi_boot=on pci=acpiirq" > nothing special happens. As in, cardbus bridge still has no IRQ, nor sound > or ieee1394 etc. Could you configure your kernel with ACPI debugging, and put "#define DEBUG" in arch/i386/kernel/pci-i386.h, then send me your dmesg after boot? --Kai |
From: web.de <ste...@we...> - 2002-01-17 19:15:43
|
I used this patch for my Gericom Supersonic M6-T and it works fine... just wanted to say something positive about this patch... thanx a lot! Stephan On Tue, 15 Jan 2002 09:50:19 +0100 (CET), Kai Germaschewski said: > > Hi! > > Time to summarize some of the experiences with ACPI PCI IRQ routing. > > o The latest ACPI release (20011218, is this still the latest?) includes > some changes to handle disabled LNKx devices. > > I think we should just report the IRQ as not routed in > acpi_get_link_irq() if the devices is not present or not decoding > resources. The current code enables the device in this case by calling > _CRS and the _SRS. I'm not even sure if _CRS is supposed to work > correctly when the device is disabled. But in any case, > acpi_get_link_irq() is called during early PCI init. I believe there > is a reason why we try to read current settings only, but don't change > anything. ({pci,acpi}_lookup_irq() is called with assign = 0, to avoid > fiddling with the hardware which is not necessary at this point. > > So we should continue on the safe path and have acpi_get_link_irq() fail > if the device is enabled. Only later, when we pci_enable_device(), we > need the IRQ line to be routed, so at that point we call > acpi_set_link_irq(), which will actually setup the IRQ routing. > > o Handling of PCI buses / bridges. I've looked at different DSDTs, and > of course (they're from the BIOS, after all), they're not consistent. > Sometimes all buses have _PRT entries, sometimes only the root bus. > I believe we should try to find a matching _PRT entry first, if not we > should assume the standard IRQ mapping on the bridge and use the _PRT > entry for the bridge (which hopefully exists). - similar to > pci_get_interrupt_pin() in drivers/pci/pci.c. I haven't done that yet. > > o I had some testing reports (which boiled down to one specific notebook) > where my initial ACPI IRQ routing patch didn't work (the standard > PCI IRQ routing code doesn't work either, though). The routing did work > when assigning the IRQ was forced on (currently we do so only if _CRS > reports no IRQ). It turned out then, that it was not the _SRS call, > though, but the eisa_set_level(). So we need to call eisa_set_level() > unconditionally in acpi_lookup_irq() when assign==1, it's an open > question if we should call acpi_pci_set_current_irq()/_SRS > unconditionally (I do so currently) > > The appended patch is my current diff, which works on every ACPI machine > I've tested so far, which isn't all that many (440BX based desktop / > laptop, VIA KT133, i810, some VIA based notebooks). You have to add > "pci=acpiirq" to the kernel command line to have ACPI IRQ routing used > instead of the standard IRQ routing code. > > Test reports are more than welcome ;-) > > --Kai > > diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-i386.h linux-2.4.17.work/arch/i386/kernel/pci-i386.h > --- linux-2.4.17.patches/arch/i386/kernel/pci-i386.h Mon Jan 14 23:55:08 2002 > +++ linux-2.4.17.work/arch/i386/kernel/pci-i386.h Fri Dec 28 23:19:14 2001 > @@ -21,6 +21,7 @@ > #define PCI_ASSIGN_ROMS 0x1000 > #define PCI_BIOS_IRQ_SCAN 0x2000 > #define PCI_ASSIGN_ALL_BUSSES 0x4000 > +#define PCI_ACPI_IRQ 0x8000 > > extern unsigned int pci_probe; > > diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-irq.c linux-2.4.17.work/arch/i386/kernel/pci-irq.c > --- linux-2.4.17.patches/arch/i386/kernel/pci-irq.c Mon Jan 14 23:55:08 2002 > +++ linux-2.4.17.work/arch/i386/kernel/pci-irq.c Tue Jan 8 00:01:32 2002 > @@ -512,6 +512,82 @@ > pirq_router_dev->slot_name); > } > > +static void pcibios_test_irq_handler(int irq, void *dev_id, struct pt_regs *regs) > +{ > +} > + > +#ifdef CONFIG_ACPI_PCI > + > +extern int acpi_pci_get_current_irq(struct pci_dev *dev, u8 pin, int *irq); > +extern int acpi_pci_set_current_irq(struct pci_dev *dev, u8 pin, int irq); > +extern int acpi_pci_get_possible_irq_mask(struct pci_dev *dev, u8 pin, int *mask); > + > +static int acpi_lookup_irq(struct pci_dev *dev, u8 pin, int assign) > +{ > + int newirq, i, irq, retval; > + char *msg = NULL; > + u32 mask; > + > + DBG("IRQ for %s:%d (%d)", dev->slot_name, pin, dev->irq); > + > + retval = acpi_pci_get_current_irq(dev, pin, &irq); > + if (retval < 0) { > + DBG(" -> failed\n"); > + return 0; > + } > + DBG(" -> irq %d", irq); > + > + retval = acpi_pci_get_possible_irq_mask(dev, pin, &mask); > + if (retval < 0) { > + DBG(" -> failed\n"); > + return 0; > + } > + DBG(" -> mask %04x", mask); > + mask &= pcibios_irq_mask; > + > + > + if (assign) { > + /* Find the best IRQ to assign */ > + newirq = 0; > + for (i = 0; i < 16; i++) { > + if (!(mask & (1 << i))) > + continue; > + if (pirq_penalty[i] < pirq_penalty[newirq] && > + !request_irq(i, pcibios_test_irq_handler, SA_SHIRQ, "pci-test", dev)) { > + free_irq(i, dev); > + newirq = i; > + } > + } > + /* Use the current IRQ if possible */ > + if (irq && ((1 << irq) & mask)) > + newirq = irq; > + > + DBG(" -> newirq=%d", newirq); > + if (newirq && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) { > + DBG(" -> assigning IRQ %d", newirq); > + if (acpi_pci_set_current_irq(dev, pin, newirq) == 0) { > + eisa_set_level_irq(newirq); > + DBG(" ... OK\n"); > + msg = "Assigned"; > + irq = newirq; > + } > + } > + } else { > + msg = "Found"; > + } > + > + if (irq) { > + printk(KERN_INFO "PCI: %s IRQ %d for device %s\n", msg, irq, dev->slot_name); > + > + dev->irq = irq; > + pirq_penalty[irq]++; > + return 1; > + } > + return 0; > +} > + > +#endif > + > static struct irq_info *pirq_get_info(struct pci_dev *dev) > { > struct irq_routing_table *rt = pirq_table; > @@ -524,38 +600,25 @@ > return NULL; > } > > -static void pcibios_test_irq_handler(int irq, void *dev_id, struct pt_regs *regs) > -{ > -} > - > -static int pcibios_lookup_irq(struct pci_dev *dev, int assign) > +static int pirq_lookup_irq(struct pci_dev *dev, u8 pin, int assign) > { > - u8 pin; > - struct irq_info *info; > - int i, pirq, newirq; > - int irq = 0; > - u32 mask; > struct irq_router *r = pirq_router; > + struct irq_info *info; > + int newirq, pirq, i, irq = 0; > struct pci_dev *dev2; > char *msg = NULL; > + u32 mask; > > if (!pirq_table) > return 0; > > - /* Find IRQ routing entry */ > - pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); > - if (!pin) { > - DBG(" -> no interrupt pin\n"); > - return 0; > - } > - pin = pin - 1; > - > DBG("IRQ for %s:%d", dev->slot_name, pin); > info = pirq_get_info(dev); > if (!info) { > DBG(" -> not found in routing table\n"); > return 0; > } > + > pirq = info->irq[pin].link; > mask = info->irq[pin].bitmap; > if (!pirq) { > @@ -636,26 +699,47 @@ > return 1; > } > > +static int pcibios_lookup_irq(struct pci_dev *dev, int assign) > +{ > + u8 pin; > + > + /* Find IRQ routing entry */ > + pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin); > + if (!pin) { > + DBG("PCI: %s: no interrupt pin\n", dev->slot_name); > + return 0; > + } > + pin -= 1; > + > +#ifdef CONFIG_ACPI_PCI > + if (pci_probe & PCI_ACPI_IRQ) > + return acpi_lookup_irq(dev, pin, assign); > +#endif > + return pirq_lookup_irq(dev, pin, assign); > +} > + > void __init pcibios_irq_init(void) > { > DBG("PCI: IRQ init\n"); > - pirq_table = pirq_find_routing_table(); > + if (!(pci_probe & PCI_ACPI_IRQ)) { > + pirq_table = pirq_find_routing_table(); > #ifdef CONFIG_PCI_BIOS > - if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) > - pirq_table = pcibios_get_irq_routing_table(); > + if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) > + pirq_table = pcibios_get_irq_routing_table(); > #endif > - if (pirq_table) { > - pirq_peer_trick(); > - pirq_find_router(); > - if (pirq_table->exclusive_irqs) { > - int i; > - for (i=0; i<16; i++) > - if (!(pirq_table->exclusive_irqs & (1 << i))) > - pirq_penalty[i] += 100; > - } > - /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ > - if (io_apic_assign_pci_irqs) > - pirq_table = NULL; > + if (pirq_table) { > + pirq_peer_trick(); > + pirq_find_router(); > + if (pirq_table->exclusive_irqs) { > + int i; > + for (i=0; i<16; i++) > + if (!(pirq_table->exclusive_irqs & (1 << i))) > + pirq_penalty[i] += 100; > + } > + /* If we're using the I/O APIC, avoid using the PCI IRQ routing table */ > + if (io_apic_assign_pci_irqs) > + pirq_table = NULL; > + } > } > } > > diff -X excl -urN linux-2.4.17.patches/arch/i386/kernel/pci-pc.c linux-2.4.17.work/arch/i386/kernel/pci-pc.c > --- linux-2.4.17.patches/arch/i386/kernel/pci-pc.c Mon Jan 14 23:55:08 2002 > +++ linux-2.4.17.work/arch/i386/kernel/pci-pc.c Fri Dec 28 23:18:54 2001 > @@ -1253,6 +1253,12 @@ > return NULL; > } > #endif > +#ifdef CONFIG_ACPI_PCI > + else if (!strcmp(str, "acpiirq")) { > + pci_probe |= PCI_ACPI_IRQ; > + return NULL; > + } > +#endif > #ifdef CONFIG_PCI_DIRECT > else if (!strcmp(str, "conf1")) { > pci_probe = PCI_PROBE_CONF1 | PCI_NO_CHECKS; > diff -X excl -urN linux-2.4.17.patches/drivers/acpi/acpi_pci.c linux-2.4.17.work/drivers/acpi/acpi_pci.c > --- linux-2.4.17.patches/drivers/acpi/acpi_pci.c Mon Jan 14 23:55:08 2002 > +++ linux-2.4.17.work/drivers/acpi/acpi_pci.c Mon Jan 7 23:22:46 2002 > @@ -119,9 +119,10 @@ > if ((0 != acpi_pci_get_status(handle, &sta)) || !(sta & 0x01)) > return -ENODEV; > > -#ifdef CONFIG_ACPI_DEBUG > - printk(KERN_INFO " link device currently %s\n", (sta & 0x02)?"enabled":"disabled"); > -#endif > + /* If disabled, return */ > + > + if (!(sta & 0x02)) > + return 0; > > /* Get the current (default) IRQ assignment */ > > @@ -146,41 +147,167 @@ > > while (resource && (bytes_unparsed > 0)) { > > - if (index != i++) > - continue; > + switch (resource->id) { > + case ACPI_RSTYPE_START_DPF: > + case ACPI_RSTYPE_END_DPF: > + break; > + default: > + i++; > + } > + > + if (i <= index) > + goto next; > > switch (resource->id) { > case ACPI_RSTYPE_IRQ: > - (*irq) = resource->data.irq.interrupts[0]; > + { > + acpi_resource_irq *p = &resource->data.irq; > + > + if (p->number_of_interrupts > 0) { > + (*irq) = p->interrupts[0]; > + } > break; > + } > case ACPI_RSTYPE_EXT_IRQ: > - (*irq) = resource->data.irq.interrupts[0]; > + { > + acpi_resource_ext_irq *p = &resource->data.extended_irq; > + if (p->number_of_interrupts > 0) { > + (*irq) = p->interrupts[0]; > + } > break; > } > + } > > if (*irq) > break; > > + next: > bytes_unparsed = bytes_unparsed - resource->length; > if (bytes_unparsed > 0) > resource = (acpi_resource*)((u8*)resource + resource->length); > } > > - if (!(*irq)) > + return 0; > +} > + > + > +static int > +acpi_pci_get_link_irq_mask ( > + acpi_handle handle, > + u32 index, > + u32 *mask) > +{ > + acpi_status status = AE_OK; > + acpi_buffer buffer = {0, NULL}; > + acpi_resource *resource = NULL; > + int bytes_unparsed = 0; > + int i = 0; > + > + if (!handle || !mask) > + return -EINVAL; > + > + status = acpi_get_possible_resources(handle, &buffer); > + if (status != AE_BUFFER_OVERFLOW) > return -ENODEV; > > - /* If disabled, enable by evaluating _SRS using default IRQ */ > + buffer.pointer = kmalloc(buffer.length, GFP_KERNEL); > + if (!buffer.pointer) > + return -ENOMEM; > + memset(buffer.pointer, 0, buffer.length); > > - if (!(sta & 0x02)) { > - acpi_buffer buffer = {resource->length, resource}; > - printk(KERN_INFO PREFIX "Enabling _PRT entry\n"); > - status = acpi_set_current_resources(handle, &buffer); > - if (ACPI_FAILURE(status)) { > - printk(KERN_WARNING PREFIX "Error evaluating _SRS, %s\n", > - acpi_format_exception(status)); > - return -ENODEV; > + status = acpi_get_possible_resources(handle, &buffer); > + if (ACPI_FAILURE(status)) { > + kfree(buffer.pointer); > + return -ENODEV; > + } > + > + resource = (acpi_resource *) buffer.pointer; > + > + bytes_unparsed = buffer.length - 16; > + > + while (resource && (bytes_unparsed > 0)) { > + > + switch (resource->id) { > + case ACPI_RSTYPE_START_DPF: > + case ACPI_RSTYPE_END_DPF: > + break; > + default: > + i++; > + } > + > + if (i <= index) > + goto next; > + > + switch (resource->id) { > + case ACPI_RSTYPE_IRQ: > + { > + acpi_resource_irq *p = &resource->data.irq; > + int j; > + > + *mask = 0; > + for (j = 0; j < p->number_of_interrupts; j++) { > + (*mask) |= (1 << p->interrupts[j]); > + } > + return 0; > } > + case ACPI_RSTYPE_EXT_IRQ: > + { > + acpi_resource_ext_irq *p = &resource->data.extended_irq; > + int j; > + > + *mask = 0; > + for (j = 0; j < p->number_of_interrupts; j++) { > + (*mask) |= (1 << p->interrupts[j]); > + } > + return 0; > + } > + } > + > + next: > + bytes_unparsed = bytes_unparsed - resource->length; > + if (bytes_unparsed > 0) > + resource = (acpi_resource *)((u8 *)resource + resource->length); > } > + > + return -ENODEV; > +} > + > + > +static int > +acpi_pci_set_link_irq ( > + acpi_handle handle, > + u32 index, > + u32 irq) > +{ > + acpi_status status = AE_OK; > + acpi_buffer buffer = {0, NULL}; > + struct { > + acpi_resource res; > + acpi_resource end; > + } resource; > + int bytes_unparsed = 0; > + int i = 0; > + > + > + if (!handle) > + return -EINVAL; > + > + memset(&resource, 0, sizeof(resource)); > + resource.res.id = ACPI_RSTYPE_IRQ; > + resource.res.length = sizeof(acpi_resource); > + resource.res.data.irq.edge_level = 0; // FIXME? > + resource.res.data.irq.active_high_low = 0; > + resource.res.data.irq.shared_exclusive = 1; > + resource.res.data.irq.number_of_interrupts = 1; > + resource.res.data.irq.interrupts[0] = irq; > + resource.end.id = ACPI_RSTYPE_END_TAG; > + > + buffer.pointer = &resource; > + buffer.length = resource.res.length + 1; > + status = acpi_set_current_resources(handle, &buffer); > + > + if (status != AE_OK) > + return -ENODEV; > > return 0; > } > @@ -243,17 +370,15 @@ > > /* Type 1 (dynamic)? */ > if (prt->source) { > - acpi_handle link_handle = NULL; > - acpi_get_handle(handle, prt->source, &link_handle); > - acpi_pci_get_link_irq(link_handle, prt->source_index, > - &prt->source_index); > - prt->source[0] = 0; > + prt->link_handle = NULL; > + acpi_get_handle(handle, prt->source, &prt->link_handle); > +/* prt->source[0] = 0; */ > } > > #ifdef CONFIG_ACPI_DEBUG > - printk(KERN_INFO " device=%02x pin=%02x irq=%d\n", > + printk(KERN_INFO " device=%02x pin=%02x source=%s source_index=%d\n", > (u32)(prt->address>>16), (u32)prt->pin, > - (u32)prt->source_index); > + prt->source, (u32)prt->source_index); > #endif /*CONFIG_ACPI_DEBUG*/ > > acpi_prt.count++; > @@ -266,6 +391,92 @@ > } > > > +static acpi_pci_routing_table * > +acpi_pci_find_routing_table_entry(struct pci_dev *dev, u8 pin) > +{ > + int busnr = dev->bus->number; > + acpi_pci_routing_table *prt = NULL; > + > + if (busnr >= ACPI_PCI_MAX_BUS) > + return 0; > + > + prt = (acpi_pci_routing_table *) acpi_prt.entry[busnr]; > + while (prt && prt->length > 0) { > + if ((prt->address >> 16) == PCI_SLOT(dev->devfn) && prt->pin == pin) > + return prt; > + prt = (acpi_pci_routing_table *) > + ((u8 *) prt + prt->length); > + } > + return prt; > +} > + > + > +int > +acpi_pci_get_current_irq(struct pci_dev *dev, u8 pin, int *irq) > +{ > + acpi_pci_routing_table *prt; > + > + *irq = 0; > + > + prt = acpi_pci_find_routing_table_entry(dev, pin); > + if (!prt) > + return -ENODEV; > + > + /* Type 1 (dynamic)? */ > + if (prt->source) { > + return acpi_pci_get_link_irq(prt->link_handle, > + prt->source_index, irq); > + } else { > + *irq = prt->source_index; > + return 0; > + } > +} > + > + > +int > +acpi_pci_get_possible_irq_mask(struct pci_dev *dev, u8 pin, int *mask) > +{ > + acpi_pci_routing_table *prt; > + > + *mask = 0; > + > + prt = acpi_pci_find_routing_table_entry(dev, pin); > + if (!prt) > + return -ENODEV; > + > + /* Type 1 (dynamic)? */ > + if (prt->source) { > + return acpi_pci_get_link_irq_mask(prt->link_handle, > + prt->source_index, mask); > + } else { > + *mask = 1 << prt->source_index; > + return 0; > + } > +} > + > + > +int > +acpi_pci_set_current_irq(struct pci_dev *dev, u8 pin, int irq) > +{ > + acpi_pci_routing_table *prt; > + > + prt = acpi_pci_find_routing_table_entry(dev, pin); > + if (!prt) > + return -ENODEV; > + > + /* Type 1 (dynamic)? */ > + if (prt->source) { > + return acpi_pci_set_link_irq(prt->link_handle, > + prt->source_index, irq); > + } else { > + if (irq != prt->source_index) > + return -ENODEV; > + > + return 0; > + } > +} > + > + > static acpi_status __init > acpi_pci_resolve_bus ( > acpi_handle handle, > @@ -432,5 +643,3 @@ > return 0; > } > > - > - > diff -X excl -urN linux-2.4.17.patches/drivers/acpi/include/actypes.h linux-2.4.17.work/drivers/acpi/include/actypes.h > --- linux-2.4.17.patches/drivers/acpi/include/actypes.h Mon Jan 14 23:55:08 2002 > +++ linux-2.4.17.work/drivers/acpi/include/actypes.h Fri Dec 28 23:16:25 2001 > @@ -1125,6 +1125,7 @@ > u32 pin; > acpi_integer address; /* here for 64-bit alignment */ > u32 source_index; > + void *link_handle; > NATIVE_CHAR source[4]; /* pad to 64 bits so sizeof() works in all cases */ > > } acpi_pci_routing_table; > > > > _______________________________________________ > Acpi-devel mailing list > Acp...@li... > https://lists.sourceforge.net/lists/listinfo/acpi-devel > > |
From: Pavel M. <pa...@uc...> - 2002-01-23 10:14:32
|
Hi! > o I had some testing reports (which boiled down to one specific notebook) > where my initial ACPI IRQ routing patch didn't work (the standard > PCI IRQ routing code doesn't work either, though). The routing did work > when assigning the IRQ was forced on (currently we do so only if _CRS > reports no IRQ). It turned out then, that it was not the _SRS call, What notebook was that? Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. |
From: Kai G. <ka...@tp...> - 2002-01-24 15:33:25
|
On Mon, 21 Jan 2002, Pavel Machek wrote: > > o I had some testing reports (which boiled down to one specific notebook) > > where my initial ACPI IRQ routing patch didn't work (the standard > > PCI IRQ routing code doesn't work either, though). The routing did work > > when assigning the IRQ was forced on (currently we do so only if _CRS > > reports no IRQ). It turned out then, that it was not the _SRS call, > > What notebook was that? Gericom 1st Supersonic M6T --Kai |
From: Mattia D. <do...@su...> - 2002-01-25 16:44:19
|
Hi, > Test reports are more than welcome [;-)] > tested on a Sony Vaio GR series (gr7/k): WOW it works [;)] now I have correct IRQ for most devices: /sbin/lspci -vt -[00]-+-00.0 Intel Corp.: Unknown device 3575 +-01.0-[01]----00.0 ATI Technologies Inc Radeon Mobility M6 LY +-1d.0 Intel Corp.: Unknown device 2482 +-1d.1 Intel Corp.: Unknown device 2484 +-1d.2 Intel Corp.: Unknown device 2487 +-1e.0-[02]--+-02.0 Texas Instruments: Unknown device 8021 | +-05.0 Ricoh Co Ltd RL5c476 II | +-05.1 Ricoh Co Ltd RL5c476 II | \-08.0 Intel Corp. 82801CAM (ICH3) Chipset Ethernet Controller +-1f.0 Intel Corp.: Unknown device 248c +-1f.1 Intel Corp.: Unknown device 248a +-1f.3 Intel Corp.: Unknown device 2483 +-1f.5 Intel Corp. AC'97 Audio Controller \-1f.6 Intel Corp.: Unknown device 2486 I just cannot find any device on irq=7 while the clean acpi patch said: Jan 24 10:29:13 inferi1 kernel: ACPI: PCI Routing Table (bus 00) Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=01 pin=00 irq=9 Jan 24 10:29:13 inferi1 kernel: link device currently disabled Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry Jan 24 10:29:13 inferi1 kernel: device=01 pin=01 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently disabled Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry Jan 24 10:29:13 inferi1 kernel: device=01 pin=02 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=01 pin=03 irq=9 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=02 pin=00 irq=9 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=1d pin=00 irq=9 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=1d pin=01 irq=9 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=1d pin=02 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently disabled Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry Jan 24 10:29:13 inferi1 kernel: device=1d pin=03 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=1f pin=01 irq=7 Jan 24 10:29:13 inferi1 kernel: ACPI: PCI Routing Table (bus 01) Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=00 pin=00 irq=9 Jan 24 10:29:13 inferi1 kernel: ACPI: PCI Routing Table (bus 02) Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=02 pin=00 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=05 pin=00 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently disabled Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry Jan 24 10:29:13 inferi1 kernel: device=05 pin=01 irq=7 Jan 24 10:29:13 inferi1 kernel: link device currently enabled Jan 24 10:29:13 inferi1 kernel: device=08 pin=00 irq=9 and this is cat /proc/interrupts with irq patch CPU0 0: 354991 XT-PIC timer 1: 8709 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 2 XT-PIC rtc 9: 56707 XT-PIC acpi, usb-uhci, usb-uhci, usb-uhci, e100, Intel ICH3, Ricoh Co Ltd RL5c476 II, Ricoh Co Ltd RL5c476 II (#2), ohci1394 11: 513 XT-PIC sonypi 12: 33337 XT-PIC PS/2 Mouse 14: 10963 XT-PIC ide0 15: 3 XT-PIC ide1 NMI: 0 ERR: 0 Anyway great job! [:)] I'll be pleased to supply any other info you need. Mattia |
From: Stephane D. <ste...@an...> - 2002-01-25 16:58:27
|
got a gr214mp as well on debian which now behaves nicely :) On Fri, 2002-01-25 at 16:39, Mattia Dongili wrote: > Hi, > > > Test reports are more than welcome [;-)] > > > tested on a Sony Vaio GR series (gr7/k): > > WOW it works [;)] > > now I have correct IRQ for most devices: > /sbin/lspci -vt > -[00]-+-00.0 Intel Corp.: Unknown device 3575 > +-01.0-[01]----00.0 ATI Technologies Inc Radeon Mobility M6 LY > +-1d.0 Intel Corp.: Unknown device 2482 > +-1d.1 Intel Corp.: Unknown device 2484 > +-1d.2 Intel Corp.: Unknown device 2487 > +-1e.0-[02]--+-02.0 Texas Instruments: Unknown device 8021 > | +-05.0 Ricoh Co Ltd RL5c476 II > | +-05.1 Ricoh Co Ltd RL5c476 II > | \-08.0 Intel Corp. 82801CAM (ICH3) Chipset Ethernet > Controller > +-1f.0 Intel Corp.: Unknown device 248c > +-1f.1 Intel Corp.: Unknown device 248a > +-1f.3 Intel Corp.: Unknown device 2483 > +-1f.5 Intel Corp. AC'97 Audio Controller > \-1f.6 Intel Corp.: Unknown device 2486 > > > I just cannot find any device on irq=7 while the clean acpi patch said: > > Jan 24 10:29:13 inferi1 kernel: ACPI: PCI Routing Table (bus 00) > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=01 pin=00 irq=9 > Jan 24 10:29:13 inferi1 kernel: link device currently disabled > Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry > Jan 24 10:29:13 inferi1 kernel: device=01 pin=01 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently disabled > Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry > Jan 24 10:29:13 inferi1 kernel: device=01 pin=02 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=01 pin=03 irq=9 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=02 pin=00 irq=9 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=1d pin=00 irq=9 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=1d pin=01 irq=9 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=1d pin=02 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently disabled > Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry > Jan 24 10:29:13 inferi1 kernel: device=1d pin=03 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=1f pin=01 irq=7 > Jan 24 10:29:13 inferi1 kernel: ACPI: PCI Routing Table (bus 01) > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=00 pin=00 irq=9 > Jan 24 10:29:13 inferi1 kernel: ACPI: PCI Routing Table (bus 02) > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=02 pin=00 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=05 pin=00 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently disabled > Jan 24 10:29:13 inferi1 kernel: ACPI: Enabling _PRT entry > Jan 24 10:29:13 inferi1 kernel: device=05 pin=01 irq=7 > Jan 24 10:29:13 inferi1 kernel: link device currently enabled > Jan 24 10:29:13 inferi1 kernel: device=08 pin=00 irq=9 > > and this is cat /proc/interrupts with irq patch > CPU0 0: 354991 XT-PIC timer > 1: 8709 XT-PIC keyboard > 2: 0 XT-PIC cascade > 8: 2 XT-PIC rtc > 9: 56707 XT-PIC acpi, usb-uhci, usb-uhci, usb-uhci, > e100, Intel ICH3, Ricoh Co Ltd RL5c476 II, Ricoh Co Ltd RL5c476 II (#2), > ohci1394 > 11: 513 XT-PIC sonypi > 12: 33337 XT-PIC PS/2 Mouse > 14: 10963 XT-PIC ide0 > 15: 3 XT-PIC ide1 > NMI: 0 > ERR: 0 > > Anyway great job! [:)] > I'll be pleased to supply any other info you need. > > Mattia > > -- ______________________________________________ "Linux philosophy: Do it Yourself" L. Torvalds Stephane Dudzinski Systems Administrator a n t e f a c t o t: +353 1 8586009 www.antefacto.com f: +353 1 8586014 |
From: jacob b. <ja...@xi...> - 2002-01-29 05:34:18
Attachments:
dmesg
|
On Tue, 2002-01-15 at 03:50, Kai Germaschewski wrote: > > Hi! > > Time to summarize some of the experiences with ACPI PCI IRQ routing. > > Test reports are more than welcome ;-) i don't seem to be getting too much success with this patch: jacob@wet-pants:log G2$ grep ^IRQ dmesg IRQ for 01:02.0:0 (0) -> failed IRQ for 01:08.0:0 (9) -> failed IRQ for 00:1f.5:1 (9) -> failed IRQ for 01:02.0:0 (0) -> failed IRQ for 00:1f.2:3 (9) -> failed IRQ for 00:1f.4:2 (9) -> failed this is a vaio r505te with 2.4.17; /proc/acpi/info: ACPI-CA Version: 20011218 Sx States Supported: S0 S3 S4 S5 OEM: " SONY" OEM machine: " U1" OEM table revision: 0x20010626 lspci -v: 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 11) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, fast devsel, latency 0 Capabilities: [88] #09 [f205] 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 11) (prog-if 00 [VGA]) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 9 Memory at f8000000 (32-bit, prefetchable) [size=64M] Memory at f4000000 (32-bit, non-prefetchable) [size=512K] Capabilities: [dc] Power Management version 2 00:1e.0 PCI bridge: Intel Corporation 82801BA PCI (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 00003000-00003fff Memory behind bridge: f4100000-f41fffff 00:1f.0 ISA bridge: Intel Corporation 82801BAM ISA Bridge (ICH2) (rev 03) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801BAM IDE U100 (rev 03) (prog-if 80 [Master]) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, medium devsel, latency 0 I/O ports at 1800 [size=16] 00:1f.2 USB Controller: Intel Corporation 82801BA(M) USB (Hub A) (rev 03) (prog-if 00 [UHCI]) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1820 [size=32] 00:1f.3 SMBus: Intel Corporation 82801BA(M) SMBus (rev 03) Subsystem: Sony Corporation: Unknown device 80e0 Flags: medium devsel, IRQ 9 I/O ports at 1810 [size=16] 00:1f.4 USB Controller: Intel Corporation 82801BA(M) USB (Hub B) (rev 03) (prog-if 00 [UHCI]) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 2400 [size=32] 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA(M) AC'97 Audio (rev 03) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1c00 [size=256] I/O ports at 1840 [size=64] 00:1f.6 Modem: Intel Corporation 82801BA(M) AC'97 Modem (rev 03) (prog-if 00 [Generic]) Subsystem: Sony Corporation: Unknown device 80e0 Flags: medium devsel, IRQ 9 I/O ports at 2000 [size=256] I/O ports at 1880 [size=128] 01:00.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8021 (rev 02) (prog-if 10 [OHCI]) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at f4101000 (32-bit, non-prefetchable) [size=2K] Memory at f4104000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 01:02.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80) Subsystem: Sony Corporation: Unknown device 80e0 Flags: bus master, medium devsel, latency 168 Memory at f4102000 (32-bit, non-prefetchable) [size=4K] Bus: primary=01, secondary=02, subordinate=05, sec-latency=176 I/O window 0: 00000000-00000003 I/O window 1: 00000000-00000003 16-bit legacy interface ports at 0001 01:08.0 Ethernet controller: Intel Corporation 82801BA(M) Ethernet (rev 03) Subsystem: Intel Corporation: Unknown device 3013 Flags: bus master, medium devsel, latency 66, IRQ 9 Memory at f4100000 (32-bit, non-prefetchable) [size=4K] I/O ports at 3000 [size=64] Capabilities: [dc] Power Management version 2 any ideas? jacob -- "In fact, can you imagine anything more terrifying than a zombie clown?" -- moby |
From: Kai G. <ka...@tp...> - 2002-01-30 22:37:06
|
On 29 Jan 2002, jacob berkman wrote: > On Tue, 2002-01-15 at 03:50, Kai Germaschewski wrote: > > > > Hi! > > > > Time to summarize some of the experiences with ACPI PCI IRQ routing. > > > > Test reports are more than welcome ;-) > > i don't seem to be getting too much success with this patch: > > jacob@wet-pants:log G2$ grep ^IRQ dmesg > IRQ for 01:02.0:0 (0) -> failed > IRQ for 01:08.0:0 (9) -> failed > IRQ for 00:1f.5:1 (9) -> failed > IRQ for 01:02.0:0 (0) -> failed > IRQ for 00:1f.2:3 (9) -> failed > IRQ for 00:1f.4:2 (9) -> failed Could you send output of dmesg after boot? (Please select ACPI DEBUG in the kernel config to have some meaningful output in there). Does your _PRT table get printed? Here I get: ACPI: PCI Routing Table (bus 00) device=01 pin=00 source=\_SB_.LNKA source_index=0 device=01 pin=01 source=\_SB_.LNKB source_index=0 device=01 pin=02 source=\_SB_.LNKC source_index=0 device=01 pin=03 source=\_SB_.LNKD source_index=0 device=07 pin=03 source=\_SB_.LNKD source_index=0 device=08 pin=00 source=\_SB_.LNKD source_index=0 device=09 pin=00 source=\_SB_.LNKC source_index=0 device=0a pin=00 source=\_SB_.LNKB source_index=0 device=0b pin=00 source=\_SB_.LNKA source_index=0 device=0c pin=00 source=\_SB_.LNKB source_index=0 device=0d pin=00 source=\_SB_.LNKB source_index=0 You should see something similar. --Kai |
From: jacob b. <ja...@xi...> - 2002-01-30 23:20:59
|
On Wed, 2002-01-30 at 17:30, Kai Germaschewski wrote: > On 29 Jan 2002, jacob berkman wrote: > > > On Tue, 2002-01-15 at 03:50, Kai Germaschewski wrote: > > > > > > Hi! > > > > > > Time to summarize some of the experiences with ACPI PCI IRQ routing. > > > > > > Test reports are more than welcome ;-) > > > > i don't seem to be getting too much success with this patch: > > > > jacob@wet-pants:log G2$ grep ^IRQ dmesg > > IRQ for 01:02.0:0 (0) -> failed > > IRQ for 01:08.0:0 (9) -> failed > > IRQ for 00:1f.5:1 (9) -> failed > > IRQ for 01:02.0:0 (0) -> failed > > IRQ for 00:1f.2:3 (9) -> failed > > IRQ for 00:1f.4:2 (9) -> failed > > Could you send output of dmesg after boot? (Please select ACPI DEBUG in > the kernel config to have some meaningful output in there). Does your _PRT > table get printed? i had attached it to the last mail, but it seems to be irrelevant as i re-built my kernel from a clean tree (2.4.17, then -xfs, then acpi, then your patch) and it seems to work fine now. sorry for the false alarm... jacob -- "In fact, can you imagine anything more terrifying than a zombie clown?" -- moby |