d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
8f27b08e87
freebsd-nq/sys/i386/include/intr_machdep.h

156 lines
5.4 KiB
C
Raw Normal View History

New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
/*-
* Copyright (c) 2003 John Baldwin <jhb@FreeBSD.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#ifndef __MACHINE_INTR_MACHDEP_H__
#define __MACHINE_INTR_MACHDEP_H__
#ifdef _KERNEL
Change the x86 code to allocate IDT vectors on-demand when an interrupt source is first enabled similar to how intr_event's now allocate ithreads on-demand. Previously, we would map IDT vectors 1:1 to IRQs. Since we only have 191 available IDT vectors for I/O interrupts, this limited us to only supporting IRQs 0-190 corresponding to the first 190 I/O APIC intpins. On many machines, however, each PCI-X bus has its own APIC even though it only has 1 or 2 devices, thus, we were reserving between 24 and 32 IRQs just for 1 or 2 devices and thus 24 or 32 IDT vectors. With this change, a machine with 100 IRQs but only 5 in use will only use up 5 IDT vectors. Also, this change provides an API (apic_alloc_vector() and apic_free_vector()) that will allow a future MSI interrupt source driver to request IDT vectors for use by MSI interrupts on x86 machines. Tested on: amd64, i386
2005-11-02 20:11:47 +00:00
/*
* The maximum number of I/O interrupts we allow. This number is rather
* arbitrary as it is just the maximum IRQ resource value. The interrupt
* source for a given IRQ maps that I/O interrupt to device interrupt
* source whether it be a pin on an interrupt controller or an MSI interrupt.
* The 16 ISA IRQs are assigned fixed IDT vectors, but all other device
* interrupts allocate IDT vectors on demand. Currently we have 191 IDT
* vectors available for device interrupts. On many systems with I/O APICs,
* a lot of the IRQs are not used, so this number can be much larger than
* 191 and still be safe since only interrupt sources in actual use will
* allocate IDT vectors.
*
MD support for PCI Message Signalled Interrupts on amd64 and i386: - Add a new apic_alloc_vectors() method to the local APIC support code to allocate N contiguous IDT vectors (aligned on a M >= N boundary). This function is used to allocate IDT vectors for a group of MSI messages. - Add MSI and MSI-X PICs. The PIC code here provides methods to manage edge-triggered MSI messages as x86 interrupt sources. In addition to the PIC methods, msi.c also includes methods to allocate and release MSI and MSI-X messages. For x86, we allow for up to 128 different MSI IRQs starting at IRQ 256 (IRQs 0-15 are reserved for ISA IRQs, 16-254 for APIC PCI IRQs, and IRQ 255 is reserved). - Add pcib_(alloc|release)_msi[x]() methods to the MD x86 PCI bridge drivers to bubble the request up to the nexus driver. - Add pcib_(alloc|release)_msi[x]() methods to the x86 nexus drivers that ask the MSI PIC code to allocate resources and IDT vectors. MFC after: 2 months
2006-11-13 22:23:34 +00:00
* The first 255 IRQs (0 - 254) are reserved for ISA IRQs and PCI intline IRQs.
* IRQ values beyond 256 are used by MSI. We leave 255 unused to avoid
* confusion since 255 is used in PCI to indicate an invalid IRQ.
Change the x86 code to allocate IDT vectors on-demand when an interrupt source is first enabled similar to how intr_event's now allocate ithreads on-demand. Previously, we would map IDT vectors 1:1 to IRQs. Since we only have 191 available IDT vectors for I/O interrupts, this limited us to only supporting IRQs 0-190 corresponding to the first 190 I/O APIC intpins. On many machines, however, each PCI-X bus has its own APIC even though it only has 1 or 2 devices, thus, we were reserving between 24 and 32 IRQs just for 1 or 2 devices and thus 24 or 32 IDT vectors. With this change, a machine with 100 IRQs but only 5 in use will only use up 5 IDT vectors. Also, this change provides an API (apic_alloc_vector() and apic_free_vector()) that will allow a future MSI interrupt source driver to request IDT vectors for use by MSI interrupts on x86 machines. Tested on: amd64, i386
2005-11-02 20:11:47 +00:00
*/
MD support for PCI Message Signalled Interrupts on amd64 and i386: - Add a new apic_alloc_vectors() method to the local APIC support code to allocate N contiguous IDT vectors (aligned on a M >= N boundary). This function is used to allocate IDT vectors for a group of MSI messages. - Add MSI and MSI-X PICs. The PIC code here provides methods to manage edge-triggered MSI messages as x86 interrupt sources. In addition to the PIC methods, msi.c also includes methods to allocate and release MSI and MSI-X messages. For x86, we allow for up to 128 different MSI IRQs starting at IRQ 256 (IRQs 0-15 are reserved for ISA IRQs, 16-254 for APIC PCI IRQs, and IRQ 255 is reserved). - Add pcib_(alloc|release)_msi[x]() methods to the MD x86 PCI bridge drivers to bubble the request up to the nexus driver. - Add pcib_(alloc|release)_msi[x]() methods to the x86 nexus drivers that ask the MSI PIC code to allocate resources and IDT vectors. MFC after: 2 months
2006-11-13 22:23:34 +00:00
#define NUM_MSI_INTS 128
#define FIRST_MSI_INT 256
#define NUM_IO_INTS (FIRST_MSI_INT + NUM_MSI_INTS)
/*
* Default base address for MSI messages on x86 platforms.
*/
#define MSI_INTEL_ADDR_BASE 0xfee00000
Change the x86 code to allocate IDT vectors on-demand when an interrupt source is first enabled similar to how intr_event's now allocate ithreads on-demand. Previously, we would map IDT vectors 1:1 to IRQs. Since we only have 191 available IDT vectors for I/O interrupts, this limited us to only supporting IRQs 0-190 corresponding to the first 190 I/O APIC intpins. On many machines, however, each PCI-X bus has its own APIC even though it only has 1 or 2 devices, thus, we were reserving between 24 and 32 IRQs just for 1 or 2 devices and thus 24 or 32 IDT vectors. With this change, a machine with 100 IRQs but only 5 in use will only use up 5 IDT vectors. Also, this change provides an API (apic_alloc_vector() and apic_free_vector()) that will allow a future MSI interrupt source driver to request IDT vectors for use by MSI interrupts on x86 machines. Tested on: amd64, i386
2005-11-02 20:11:47 +00:00
/*
* - 1 ??? dummy counter.
* - 2 counters for each I/O interrupt.
* - 1 counter for each CPU for lapic timer.
* - 7 counters for each CPU for IPI counters for SMP.
*/
#ifdef SMP
#define INTRCNT_COUNT (1 + NUM_IO_INTS * 2 + (1 + 7) * MAXCPU)
Oops, fix sign bug in #ifdef for value of INTRCNT_COUNT. PR: kern/99870 Submitted by: jkim MFC after: 3 days
2006-10-10 19:26:35 +00:00
#else
#define INTRCNT_COUNT (1 + NUM_IO_INTS * 2 + 1)
Change the x86 code to allocate IDT vectors on-demand when an interrupt source is first enabled similar to how intr_event's now allocate ithreads on-demand. Previously, we would map IDT vectors 1:1 to IRQs. Since we only have 191 available IDT vectors for I/O interrupts, this limited us to only supporting IRQs 0-190 corresponding to the first 190 I/O APIC intpins. On many machines, however, each PCI-X bus has its own APIC even though it only has 1 or 2 devices, thus, we were reserving between 24 and 32 IRQs just for 1 or 2 devices and thus 24 or 32 IDT vectors. With this change, a machine with 100 IRQs but only 5 in use will only use up 5 IDT vectors. Also, this change provides an API (apic_alloc_vector() and apic_free_vector()) that will allow a future MSI interrupt source driver to request IDT vectors for use by MSI interrupts on x86 machines. Tested on: amd64, i386
2005-11-02 20:11:47 +00:00
#endif
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
#ifndef LOCORE
typedef void inthand_t(u_int cs, u_int ef, u_int esp, u_int ss);
#define IDTVEC(name) __CONCAT(X,name)
struct intsrc;
/*
* Methods that a PIC provides to mask/unmask a given interrupt source,
* "turn on" the interrupt on the CPU side by setting up an IDT entry, and
* return the vector associated with this source.
*/
struct pic {
void (*pic_enable_source)(struct intsrc *);
Optimize intr_execute_handlers() by combining the pic_disable_source() and pic_eoi_source() into one call. This halves the number of spinlock operations and indirect function calls in the normal case of handling a normal (ithread) interrupt. Optimize the atpic and ioapic drivers to use inlines where appropriate in supporting the intr_execute_handlers() change. This knocks 900ns, or roughly 1350 cycles, off of the time spent servicing an interrupt in the common case on my 1.5GHz P4 uniprocessor system. SMP systems likely won't see as much of a gain due to the ioapic being more efficient than the atpic. I'll investigate porting this to amd64 soon. Reviewed by: jhb
2004-08-02 15:31:10 +00:00
void (*pic_disable_source)(struct intsrc *, int);
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
void (*pic_eoi_source)(struct intsrc *);
void (*pic_enable_intr)(struct intsrc *);
int (*pic_vector)(struct intsrc *);
int (*pic_source_pending)(struct intsrc *);
Change the x86 interrupt code to suspend/resume interrupt controllers (PICs) rather than interrupt sources. This allows interrupt controllers with no interrupt pics (such as the 8259As when APIC is in use) to participate in suspend/resume. - Always register the 8259A PICs even if we don't use any of their pins. - Explicitly reset the 8259As on resume on amd64 if 'device atpic' isn't included. - Add a "dummy" PIC for the local APIC on the BSP to reset the local APIC on resume. This gets suspend/resume working with APIC on UP systems. SMP still needs more work to bring the APs back to life. The MFC after is tentative. Tested by: anholt (i386) Submitted by: Andrea Bittau <a.bittau at cs.ucl.ac.uk> (3) MFC after: 1 week
2006-10-10 23:23:12 +00:00
void (*pic_suspend)(struct pic *);
void (*pic_resume)(struct pic *);
- Add a new pic method pic_config_intr() to set the trigger mode and polarity for a specified IRQ. The intr_config_intr() function wraps this pic method hiding the IRQ to interrupt source lookup. - Add a config_intr() method to the atpic(4) driver that reconfigures the interrupt using the ELCR if possible and returns an error otherwise. - Add a config_intr() method to the apic(4) driver that just logs any requests that would change the existing programming under bootverbose. Currently, the only changes the apic(4) driver receives are due to bugs in the acpi(4) driver and its handling of link devices, hence the reason for such requests currently being ignored. - Have the nexus(4) driver on i386 implement the bus_config_intr() function by calling intr_config_intr().
2004-05-04 21:02:56 +00:00
int (*pic_config_intr)(struct intsrc *, enum intr_trigger,
enum intr_polarity);
Rework how we wire up interrupt sources to CPUs: - Throw out all of the logical APIC ID stuff. The Intel docs are somewhat ambiguous, but it seems that the "flat" cluster model we are currently using is only supported on Pentium and P6 family CPUs. The other "hierarchy" cluster model that is supported on all Intel CPUs with local APICs is severely underdocumented. For example, it's not clear if the OS needs to glean the topology of the APIC hierarchy from somewhere (neither ACPI nor MP Table include it) and setup the logical clusters based on the physical hierarchy or not. Not only that, but on certain Intel chipsets, even though there were 4 CPUs in a logical cluster, all the interrupts were only sent to one CPU anyway. - We now bind interrupts to individual CPUs using physical addressing via the local APIC IDs. This code has also moved out of the ioapic PIC driver and into the common interrupt source code so that it can be shared with MSI interrupt sources since MSI is addressed to APICs the same way that I/O APIC pins are. - Interrupt source classes grow a new method pic_assign_cpu() to bind an interrupt source to a specific local APIC ID. - The SMP code now tells the interrupt code which CPUs are avaiable to handle interrupts in a simpler and more intuitive manner. For one thing, it means we could now choose to not route interrupts to HT cores if we wanted to (this code is currently in place in fact, but under an #if 0 for now). - For now we simply do static round-robin of IRQs to CPUs when the first interrupt handler just as before, with the change that IRQs are now bound to individual CPUs rather than groups of up to 4 CPUs. - Because the IRQ to CPU mapping has now been moved up a layer, it would be easier to manage this mapping from higher levels. For example, we could allow drivers to specify a CPU affinity map for their interrupts, or we could allow a userland tool to bind IRQs to specific CPUs. The MFC is tentative, but I want to see if this fixes problems some folks had with UP APIC kernels on 6.0 on SMP machines (an SMP kernel would work fine, but a UP APIC kernel (such as GENERIC in RELENG_6) would lose interrupts). MFC after: 1 week
2006-02-28 22:24:55 +00:00
void (*pic_assign_cpu)(struct intsrc *, u_int apic_id);
Change the x86 interrupt code to suspend/resume interrupt controllers (PICs) rather than interrupt sources. This allows interrupt controllers with no interrupt pics (such as the 8259As when APIC is in use) to participate in suspend/resume. - Always register the 8259A PICs even if we don't use any of their pins. - Explicitly reset the 8259As on resume on amd64 if 'device atpic' isn't included. - Add a "dummy" PIC for the local APIC on the BSP to reset the local APIC on resume. This gets suspend/resume working with APIC on UP systems. SMP still needs more work to bring the APs back to life. The MFC after is tentative. Tested by: anholt (i386) Submitted by: Andrea Bittau <a.bittau at cs.ucl.ac.uk> (3) MFC after: 1 week
2006-10-10 23:23:12 +00:00
STAILQ_ENTRY(pic) pics;
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
};
Optimize intr_execute_handlers() by combining the pic_disable_source() and pic_eoi_source() into one call. This halves the number of spinlock operations and indirect function calls in the normal case of handling a normal (ithread) interrupt. Optimize the atpic and ioapic drivers to use inlines where appropriate in supporting the intr_execute_handlers() change. This knocks 900ns, or roughly 1350 cycles, off of the time spent servicing an interrupt in the common case on my 1.5GHz P4 uniprocessor system. SMP systems likely won't see as much of a gain due to the ioapic being more efficient than the atpic. I'll investigate porting this to amd64 soon. Reviewed by: jhb
2004-08-02 15:31:10 +00:00
/* Flags for pic_disable_source() */
enum {
PIC_EOI,
PIC_NO_EOI,
};
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
/*
* An interrupt source. The upper-layer code uses the PIC methods to
* control a given source. The lower-layer PIC drivers can store additional
* private data in a given interrupt source such as an interrupt pin number
* or an I/O APIC pointer.
*/
struct intsrc {
struct pic *is_pic;
Reorganize the interrupt handling code a bit to make a few things cleaner and increase flexibility to allow various different approaches to be tried in the future. - Split struct ithd up into two pieces. struct intr_event holds the list of interrupt handlers associated with interrupt sources. struct intr_thread contains the data relative to an interrupt thread. Currently we still provide a 1:1 relationship of events to threads with the exception that events only have an associated thread if there is at least one threaded interrupt handler attached to the event. This means that on x86 we no longer have 4 bazillion interrupt threads with no handlers. It also means that interrupt events with only INTR_FAST handlers no longer have an associated thread either. - Renamed struct intrhand to struct intr_handler to follow the struct intr_foo naming convention. This did require renaming the powerpc MD struct intr_handler to struct ppc_intr_handler. - INTR_FAST no longer implies INTR_EXCL on all architectures except for powerpc. This means that multiple INTR_FAST handlers can attach to the same interrupt and that INTR_FAST and non-INTR_FAST handlers can attach to the same interrupt. Sharing INTR_FAST handlers may not always be desirable, but having sio(4) and uhci(4) fight over an IRQ isn't fun either. Drivers can always still use INTR_EXCL to ask for an interrupt exclusively. The way this sharing works is that when an interrupt comes in, all the INTR_FAST handlers are executed first, and if any threaded handlers exist, the interrupt thread is scheduled afterwards. This type of layout also makes it possible to investigate using interrupt filters ala OS X where the filter determines whether or not its companion threaded handler should run. - Aside from the INTR_FAST changes above, the impact on MD interrupt code is mostly just 's/ithread/intr_event/'. - A new MI ddb command 'show intrs' walks the list of interrupt events dumping their state. It also has a '/v' verbose switch which dumps info about all of the handlers attached to each event. - We currently don't destroy an interrupt thread when the last threaded handler is removed because it would suck for things like ppbus(8)'s braindead behavior. The code is present, though, it is just under #if 0 for now. - Move the code to actually execute the threaded handlers for an interrrupt event into a separate function so that ithread_loop() becomes more readable. Previously this code was all in the middle of ithread_loop() and indented halfway across the screen. - Made struct intr_thread private to kern_intr.c and replaced td_ithd with a thread private flag TDP_ITHREAD. - In statclock, check curthread against idlethread directly rather than curthread's proc against idlethread's proc. (Not really related to intr changes) Tested on: alpha, amd64, i386, sparc64 Tested on: arm, ia64 (older version of patch by cognet and marcel)
2005-10-25 19:48:48 +00:00
struct intr_event *is_event;
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
u_long *is_count;
u_long *is_straycount;
u_int is_index;
Rework how we wire up interrupt sources to CPUs: - Throw out all of the logical APIC ID stuff. The Intel docs are somewhat ambiguous, but it seems that the "flat" cluster model we are currently using is only supported on Pentium and P6 family CPUs. The other "hierarchy" cluster model that is supported on all Intel CPUs with local APICs is severely underdocumented. For example, it's not clear if the OS needs to glean the topology of the APIC hierarchy from somewhere (neither ACPI nor MP Table include it) and setup the logical clusters based on the physical hierarchy or not. Not only that, but on certain Intel chipsets, even though there were 4 CPUs in a logical cluster, all the interrupts were only sent to one CPU anyway. - We now bind interrupts to individual CPUs using physical addressing via the local APIC IDs. This code has also moved out of the ioapic PIC driver and into the common interrupt source code so that it can be shared with MSI interrupt sources since MSI is addressed to APICs the same way that I/O APIC pins are. - Interrupt source classes grow a new method pic_assign_cpu() to bind an interrupt source to a specific local APIC ID. - The SMP code now tells the interrupt code which CPUs are avaiable to handle interrupts in a simpler and more intuitive manner. For one thing, it means we could now choose to not route interrupts to HT cores if we wanted to (this code is currently in place in fact, but under an #if 0 for now). - For now we simply do static round-robin of IRQs to CPUs when the first interrupt handler just as before, with the change that IRQs are now bound to individual CPUs rather than groups of up to 4 CPUs. - Because the IRQ to CPU mapping has now been moved up a layer, it would be easier to manage this mapping from higher levels. For example, we could allow drivers to specify a CPU affinity map for their interrupts, or we could allow a userland tool to bind IRQs to specific CPUs. The MFC is tentative, but I want to see if this fixes problems some folks had with UP APIC kernels on 6.0 on SMP machines (an SMP kernel would work fine, but a UP APIC kernel (such as GENERIC in RELENG_6) would lose interrupts). MFC after: 1 week
2006-02-28 22:24:55 +00:00
u_int is_enabled:1;
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
};
Change the i386 code to pass the interrupt vector as a separate argument rather than embedding it in the intrframe as if_vec. This reduces diffs with amd64 somewhat. - Remove cf_vec from clockframe (it wasn't used anyway) and stop pushing dummy vector arguments for ipi_bitmap_handler() and lapic_handle_timer() since clockframe == trapframe now. - Fix ddb to handle stack traces across interrupt entry points that just have a trapframe on their stack and not a trapframe + vector. - Change intr_execute_handlers() to take a trapframe rather than an intrframe pointer. - Change lapic_handle_intr() and atpic_handle_intr() to take a vector and trapframe rather than an intrframe. - GC struct intrframe now that nothing uses it anymore. - GC CLOCK_TO_TRAPFRAME() and INTR_TO_TRAPFRAME(). Reviewed by: bde Requested by: peter
2005-12-05 22:39:09 +00:00
struct trapframe;
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
extern struct mtx icu_lock;
Tweak the ELCR support slightly. Explicitly probe the ELCR during boot instead of burying that in the atpic(4) code as atpic(4) is not the only user of elcr(4). Change the elcr(4) code to export a global elcr_found variable that other code can check to see if a valid ELCR was found. MFC after: 1 month
2005-01-18 20:24:47 +00:00
extern int elcr_found;
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
Add a simple mini-driver for the ELCR register. Originally, the ELCR register controlled the trigger mode and polarity of EISA interrupts. However, it appears that most (all?) PCI systems use the ELCR to manage the trigger mode and polarity of ISA interrupts as well since ISA IRQs used to route PCI interrupts need to be level triggered with active low polarity. We check to see if the ELCR exists by sanity checking the value we get back ensuring that IRQS 0 (8254), 1 (atkbd), 2 (the link from the slave PIC), and 8 (RTC) are all clear indicating edge trigger and active high polarity. This mini-driver will be used by the atpic driver to manage the trigger and polarity of ISA IRQs. Also, the mptable parsing code will use this mini driver rather than examining the ELCR directly.
2004-05-04 20:07:46 +00:00
/* XXX: The elcr_* prototypes probably belong somewhere else. */
int elcr_probe(void);
enum intr_trigger elcr_read_trigger(u_int irq);
void elcr_resume(void);
void elcr_write_trigger(u_int irq, enum intr_trigger trigger);
Rework how we wire up interrupt sources to CPUs: - Throw out all of the logical APIC ID stuff. The Intel docs are somewhat ambiguous, but it seems that the "flat" cluster model we are currently using is only supported on Pentium and P6 family CPUs. The other "hierarchy" cluster model that is supported on all Intel CPUs with local APICs is severely underdocumented. For example, it's not clear if the OS needs to glean the topology of the APIC hierarchy from somewhere (neither ACPI nor MP Table include it) and setup the logical clusters based on the physical hierarchy or not. Not only that, but on certain Intel chipsets, even though there were 4 CPUs in a logical cluster, all the interrupts were only sent to one CPU anyway. - We now bind interrupts to individual CPUs using physical addressing via the local APIC IDs. This code has also moved out of the ioapic PIC driver and into the common interrupt source code so that it can be shared with MSI interrupt sources since MSI is addressed to APICs the same way that I/O APIC pins are. - Interrupt source classes grow a new method pic_assign_cpu() to bind an interrupt source to a specific local APIC ID. - The SMP code now tells the interrupt code which CPUs are avaiable to handle interrupts in a simpler and more intuitive manner. For one thing, it means we could now choose to not route interrupts to HT cores if we wanted to (this code is currently in place in fact, but under an #if 0 for now). - For now we simply do static round-robin of IRQs to CPUs when the first interrupt handler just as before, with the change that IRQs are now bound to individual CPUs rather than groups of up to 4 CPUs. - Because the IRQ to CPU mapping has now been moved up a layer, it would be easier to manage this mapping from higher levels. For example, we could allow drivers to specify a CPU affinity map for their interrupts, or we could allow a userland tool to bind IRQs to specific CPUs. The MFC is tentative, but I want to see if this fixes problems some folks had with UP APIC kernels on 6.0 on SMP machines (an SMP kernel would work fine, but a UP APIC kernel (such as GENERIC in RELENG_6) would lose interrupts). MFC after: 1 week
2006-02-28 22:24:55 +00:00
#ifdef SMP
Change the x86 interrupt code to use FreeBSD CPU IDs (i.e. PCPU_GET(cpuid)) rather than local APIC IDs to keep track of CPUs which can handle interrupts.
2007-03-06 17:16:47 +00:00
void intr_add_cpu(u_int cpu);
Rework how we wire up interrupt sources to CPUs: - Throw out all of the logical APIC ID stuff. The Intel docs are somewhat ambiguous, but it seems that the "flat" cluster model we are currently using is only supported on Pentium and P6 family CPUs. The other "hierarchy" cluster model that is supported on all Intel CPUs with local APICs is severely underdocumented. For example, it's not clear if the OS needs to glean the topology of the APIC hierarchy from somewhere (neither ACPI nor MP Table include it) and setup the logical clusters based on the physical hierarchy or not. Not only that, but on certain Intel chipsets, even though there were 4 CPUs in a logical cluster, all the interrupts were only sent to one CPU anyway. - We now bind interrupts to individual CPUs using physical addressing via the local APIC IDs. This code has also moved out of the ioapic PIC driver and into the common interrupt source code so that it can be shared with MSI interrupt sources since MSI is addressed to APICs the same way that I/O APIC pins are. - Interrupt source classes grow a new method pic_assign_cpu() to bind an interrupt source to a specific local APIC ID. - The SMP code now tells the interrupt code which CPUs are avaiable to handle interrupts in a simpler and more intuitive manner. For one thing, it means we could now choose to not route interrupts to HT cores if we wanted to (this code is currently in place in fact, but under an #if 0 for now). - For now we simply do static round-robin of IRQs to CPUs when the first interrupt handler just as before, with the change that IRQs are now bound to individual CPUs rather than groups of up to 4 CPUs. - Because the IRQ to CPU mapping has now been moved up a layer, it would be easier to manage this mapping from higher levels. For example, we could allow drivers to specify a CPU affinity map for their interrupts, or we could allow a userland tool to bind IRQs to specific CPUs. The MFC is tentative, but I want to see if this fixes problems some folks had with UP APIC kernels on 6.0 on SMP machines (an SMP kernel would work fine, but a UP APIC kernel (such as GENERIC in RELENG_6) would lose interrupts). MFC after: 1 week
2006-02-28 22:24:55 +00:00
#endif
o break newbus api: add a new argument of type driver_filter_t to bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@
2007-02-23 12:19:07 +00:00
int intr_add_handler(const char *name, int vector, driver_filter_t filter,
driver_intr_t handler, void *arg, enum intr_type flags, void **cookiep);
- Add a new pic method pic_config_intr() to set the trigger mode and polarity for a specified IRQ. The intr_config_intr() function wraps this pic method hiding the IRQ to interrupt source lookup. - Add a config_intr() method to the atpic(4) driver that reconfigures the interrupt using the ELCR if possible and returns an error otherwise. - Add a config_intr() method to the apic(4) driver that just logs any requests that would change the existing programming under bootverbose. Currently, the only changes the apic(4) driver receives are due to bugs in the acpi(4) driver and its handling of link devices, hence the reason for such requests currently being ignored. - Have the nexus(4) driver on i386 implement the bus_config_intr() function by calling intr_config_intr().
2004-05-04 21:02:56 +00:00
int intr_config_intr(int vector, enum intr_trigger trig,
enum intr_polarity pol);
Change the i386 code to pass the interrupt vector as a separate argument rather than embedding it in the intrframe as if_vec. This reduces diffs with amd64 somewhat. - Remove cf_vec from clockframe (it wasn't used anyway) and stop pushing dummy vector arguments for ipi_bitmap_handler() and lapic_handle_timer() since clockframe == trapframe now. - Fix ddb to handle stack traces across interrupt entry points that just have a trapframe on their stack and not a trapframe + vector. - Change intr_execute_handlers() to take a trapframe rather than an intrframe pointer. - Change lapic_handle_intr() and atpic_handle_intr() to take a vector and trapframe rather than an intrframe. - GC struct intrframe now that nothing uses it anymore. - GC CLOCK_TO_TRAPFRAME() and INTR_TO_TRAPFRAME(). Reviewed by: bde Requested by: peter
2005-12-05 22:39:09 +00:00
void intr_execute_handlers(struct intsrc *isrc, struct trapframe *frame);
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
struct intsrc *intr_lookup_source(int vector);
Change the x86 interrupt code to suspend/resume interrupt controllers (PICs) rather than interrupt sources. This allows interrupt controllers with no interrupt pics (such as the 8259As when APIC is in use) to participate in suspend/resume. - Always register the 8259A PICs even if we don't use any of their pins. - Explicitly reset the 8259As on resume on amd64 if 'device atpic' isn't included. - Add a "dummy" PIC for the local APIC on the BSP to reset the local APIC on resume. This gets suspend/resume working with APIC on UP systems. SMP still needs more work to bring the APs back to life. The MFC after is tentative. Tested by: anholt (i386) Submitted by: Andrea Bittau <a.bittau at cs.ucl.ac.uk> (3) MFC after: 1 week
2006-10-10 23:23:12 +00:00
int intr_register_pic(struct pic *pic);
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
int intr_register_source(struct intsrc *isrc);
int intr_remove_handler(void *cookie);
void intr_resume(void);
void intr_suspend(void);
Add a simple 'intrcnt_add' function that other MD code can use to add a single named counter to the interrupt counts without having to fake up an entire interrupt source.
2004-12-23 20:34:18 +00:00
void intrcnt_add(const char *name, u_long **countp);
MD support for PCI Message Signalled Interrupts on amd64 and i386: - Add a new apic_alloc_vectors() method to the local APIC support code to allocate N contiguous IDT vectors (aligned on a M >= N boundary). This function is used to allocate IDT vectors for a group of MSI messages. - Add MSI and MSI-X PICs. The PIC code here provides methods to manage edge-triggered MSI messages as x86 interrupt sources. In addition to the PIC methods, msi.c also includes methods to allocate and release MSI and MSI-X messages. For x86, we allow for up to 128 different MSI IRQs starting at IRQ 256 (IRQs 0-15 are reserved for ISA IRQs, 16-254 for APIC PCI IRQs, and IRQ 255 is reserved). - Add pcib_(alloc|release)_msi[x]() methods to the MD x86 PCI bridge drivers to bubble the request up to the nexus driver. - Add pcib_(alloc|release)_msi[x]() methods to the x86 nexus drivers that ask the MSI PIC code to allocate resources and IDT vectors. MFC after: 2 months
2006-11-13 22:23:34 +00:00
int msi_alloc(device_t dev, int count, int maxcount, int *irqs, int *newirq,
int *newcount);
Sort function prototypes.
2006-12-12 19:24:45 +00:00
void msi_init(void);
MD support for PCI Message Signalled Interrupts on amd64 and i386: - Add a new apic_alloc_vectors() method to the local APIC support code to allocate N contiguous IDT vectors (aligned on a M >= N boundary). This function is used to allocate IDT vectors for a group of MSI messages. - Add MSI and MSI-X PICs. The PIC code here provides methods to manage edge-triggered MSI messages as x86 interrupt sources. In addition to the PIC methods, msi.c also includes methods to allocate and release MSI and MSI-X messages. For x86, we allow for up to 128 different MSI IRQs starting at IRQ 256 (IRQs 0-15 are reserved for ISA IRQs, 16-254 for APIC PCI IRQs, and IRQ 255 is reserved). - Add pcib_(alloc|release)_msi[x]() methods to the MD x86 PCI bridge drivers to bubble the request up to the nexus driver. - Add pcib_(alloc|release)_msi[x]() methods to the x86 nexus drivers that ask the MSI PIC code to allocate resources and IDT vectors. MFC after: 2 months
2006-11-13 22:23:34 +00:00
int msi_release(int* irqs, int count);
int msix_alloc(device_t dev, int index, int *irq, int *new);
Expand the MSI/MSI-X API to address some deficiencies in the MSI-X support. - First off, device drivers really do need to know if they are allocating MSI or MSI-X messages. MSI requires allocating powerof2() messages for example where MSI-X does not. To address this, split out the MSI-X support from pci_msi_count() and pci_alloc_msi() into new driver-visible functions pci_msix_count() and pci_alloc_msix(). As a result, pci_msi_count() now just returns a count of the max supported MSI messages for the device, and pci_alloc_msi() only tries to allocate MSI messages. To get a count of the max supported MSI-X messages, use pci_msix_count(). To allocate MSI-X messages, use pci_alloc_msix(). pci_release_msi() still handles both MSI and MSI-X messages, however. As a result of this change, drivers using the existing API will only use MSI messages and will no longer try to use MSI-X messages. - Because MSI-X allows for each message to have its own data and address values (and thus does not require all of the messages to have their MD vectors allocated as a group), some devices allow for "sparse" use of MSI-X message slots. For example, if a device supports 8 messages but the OS is only able to allocate 2 messages, the device may make the best use of 2 IRQs if it enables the messages at slots 1 and 4 rather than default of using the first N slots (or indicies) at 1 and 2. To support this, add a new pci_remap_msix() function that a driver may call after a successful pci_alloc_msix() (but before allocating any of the SYS_RES_IRQ resources) to allow the allocated IRQ resources to be assigned to different message indices. For example, from the earlier example, after pci_alloc_msix() returned a value of 2, the driver would call pci_remap_msix() passing in array of integers { 1, 4 } as the new message indices to use. The rid's for the SYS_RES_IRQ resources will always match the message indices. Thus, after the call to pci_remap_msix() the driver would be able to access the first message in slot 1 at SYS_RES_IRQ rid 1, and the second message at slot 4 at SYS_RES_IRQ rid 4. Note that the message slots/indices are 1-based rather than 0-based so that they will always correspond to the rid values (SYS_RES_IRQ rid 0 is reserved for the legacy INTx interrupt). To support this API, a new PCIB_REMAP_MSIX() method was added to the pcib interface to change the message index for a single IRQ. Tested by: scottl
2007-01-22 21:48:44 +00:00
int msix_remap(int index, int irq);
MD support for PCI Message Signalled Interrupts on amd64 and i386: - Add a new apic_alloc_vectors() method to the local APIC support code to allocate N contiguous IDT vectors (aligned on a M >= N boundary). This function is used to allocate IDT vectors for a group of MSI messages. - Add MSI and MSI-X PICs. The PIC code here provides methods to manage edge-triggered MSI messages as x86 interrupt sources. In addition to the PIC methods, msi.c also includes methods to allocate and release MSI and MSI-X messages. For x86, we allow for up to 128 different MSI IRQs starting at IRQ 256 (IRQs 0-15 are reserved for ISA IRQs, 16-254 for APIC PCI IRQs, and IRQ 255 is reserved). - Add pcib_(alloc|release)_msi[x]() methods to the MD x86 PCI bridge drivers to bubble the request up to the nexus driver. - Add pcib_(alloc|release)_msi[x]() methods to the x86 nexus drivers that ask the MSI PIC code to allocate resources and IDT vectors. MFC after: 2 months
2006-11-13 22:23:34 +00:00
int msix_release(int irq);
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers. By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
2003-11-03 21:25:52 +00:00
#endif /* !LOCORE */
#endif /* _KERNEL */
#endif /* !__MACHINE_INTR_MACHDEP_H__ */
Reference in New Issue Copy Permalink