PIC Edge/level detetction

[yassin]

What make the differenece for my kernel code if i choose the Level triggered interrupts (instead of the edge detetction) when programming the 8259A PIC?

[Candy]

What make the differenece for my kernel code if i choose the Level triggered interrupts (instead of the edge detetction) when programming the 8259A PIC?

Edge triggered interrupts activate at the moment your device sets the interrupt line at high. Level triggered interrupts activate while your device keeps the interrupt line high.

Choose the one your device indicates it needs. Commonly level-triggered works best, because you are still interrupted if you don't respond to it directly. Not entirely sure on this, anybody know whether edge-triggered interrupts are stored?

I think the main difference is that a level-triggered interrupt will re-interrupt the CPU after handling it if the line doesn't go back down.

[kataklinger]

In PIC there's a register (i don't remeber the name) which will save panding interrupts. When CPU enables interrupts, PIC will interrupt CPU if there is any bit set in the panding interrupt register.

<edit>
The name of the register is IRR or interrupt request register.
</edit>

[Pype.Clicker]

What make the differenece for my kernel code if i choose the Level triggered interrupts (instead of the edge detetction) when programming the 8259A PIC?

Make sure that you know what you're doing here ... it's very likely that the PC platform only supports one of the PIC mode (e.g. levels may be maintained for a too short or too long period to work properly), and that the other mode is there for other applications of the 8259A. Depending on your chipset, either the "wrong" value will be ignored (e.g. the chipset has been hardwired to work in the correct mode only) or you might miss events, or receive duplicates of the events.

[yassine]

i've found some intereting infos on the wikipedia

In computing, an edge-triggered interrupt is a class of interrupts that are triggered only on the rising edge of the assertion of the interrupt request line. These types of interrupts can typically only identify the presence of an interrupt request. When another interrupt is generated an edge triggered interrupt will not be able to distinguish it since the line is already asserted.

Multiple devices typically cannot share an edge-triggered interrupt line. Because the generation of another interrupt will go unoticed, devices in such a configuration could go unserviced. The ISA bus in particular is know for this issue. Many ISA cards cannot be probed for interrupt status, and may still will stop responding or lockup the system if service when they did not generate an interrupt. Therefore, special care must be taken to insure such systems do not share interrupt lines.

In computing, a level-triggered interrupt is a class of interrupts that can be triggerd on either the rising edge or falling edge of the interrupt request line. An assertion of the line changes the it from low to high or high to low. This class of interrupts allows multiple devices to efficiently share the same interrupt line.

Since the ISA bus does not support level triggered interrupts, level trigger mode may not be used for interrupts connected to ISA devices. This means that on PC/XT, PC/AT, and MCA systems the 8259 must be programmed for edge triggered mode. On newer EISA, PCI, and later systems an Edge/Level Control Registers (ELCRs) controls the mode per IRQ line, effectivly making the mode of the 8259 irrelevant for such systems with ISA buses. The ELCR is programmed by the BIOS at system startup for correct operation.

The ELCRs are located 0x4d0 and 0x4d1 in the x86 I/O address space. They are 8-bits wide, each bit corresponding to an IRQ from the 8259s. When a bit is set, the IRQ is in level triggered mode; otherwise, the IRQ is in edge triggered mode.

[yassin]

extarct from an article on the microsoft site (http://www.microsoft.com/whdc/system/sysperf/apic.mspx)

The following examples should help to clarify the specific technical problems that are associated with interrupt sharing. When devices are forced to share interrupts, triggering an IRQ causes the following sequence of events:

Level-Triggered (PCI) Case:

1. The processor retrieves an IDT vector from the interrupt controller and does a look-up in the IDT to find a dispatch address.

2. The code at the dispatch address examines the interrupt service routines that were registered by device drivers for that IRQ. It then calls them in the order in which they are listed.

3. Each interrupt service routine (ISR) probes the hardware for the device and determines if the device is, in fact, interrupting.

? If the device is interrupting, the ISR queues any work to be done and causes the hardware to stop interrupting. (At this point, the device hardware has been accessed at least twice.) The ISR then returns a value indicating that the interrupt has been handled. The operating system then acknowledges the interrupt.

? If the device is not interrupting, the ISR returns a value indicating that the interrupt was not caused by its device. The operating system then goes on to the next ISR in the chain and returns to step 3.

Edge-Triggered Case:

1. The processor retrieves an IDT vector from the interrupt controller and does a look-up in the IDT to find a dispatch address. (Same as level-triggered.)

2. The code at the dispatch address examines the interrupt service routines that were registered by device drivers for that IRQ. It then calls them in the order in which they are listed. (Same as level-triggered.)

3. The operating system acknowledges the interrupt, so that any future edge-triggered interrupts are not lost.

4. The operating system calls the first ISR in the chain.

5. The ISR probes the hardware and attempts to handle the interrupt.

6. If there are additional ISRs, the operating system goes on to the next one and returns to step 5.

Note that with edge-triggered devices, it is necessary to iterate through the entire chain of ISRs each time any device on that IRQ interrupts, because there is no guarantee that a device will reassert an unhandled interrupt after it is acknowledged at the interrupt controller.

[Pype.Clicker]

extarct from an article on the microsoft site (http://www.microsoft.com/whdc/system/sysperf/apic.mspx)

Level-Triggered (PCI) Case:

Edge-Triggered Case:

You'll notice that they explicitly mention "PCI" for level-triggered. And iirc, no line of th PCI bus are directly connected to the PIC. Instead, they go through a chipset function that will decode PCI signals and issue an interrupt request on one of the PIC lines.

The fact you can mix PCI (level-triggered) and ISA (edge-triggered) in a single PC doesn't mean in any way that you should mess with the edge/level setup of the PIC (which you can only change as a whole, not on a per-line basis, iirc).

[yassine]

which you can only change as a whole, not on a per-line basis

that's right, 8259A uses a single bit to store the detection mode. but in some boards there is an extended mode register at 0x4d0 and 0x4d1 to set the mode per line. however, it seems in the pc/at the 8259A does not work normally with level interrupts.

[Pype.Clicker]

however, it seems in the pc/at the 8259A does not work normally with level interrupts.

i would assume the BIOS to set those appropriately to what the "fake" PIC might need to interprete motherboard signals. That's likely to be set up on boot-time and should not be messed with unless you exactly know what you're doing.

[kataklinger]

Use I/O APIC instead