Messages in this thread | | | Date | Tue, 24 Aug 1999 10:41:40 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: problem with edge and level triggered interrupts |
| |
On Tue, 24 Aug 1999, Anil Kumar S R wrote:
> Hi, > I want to have some clarification with regards to interrupts > being edge or level triggered. > > 1. How can I decide whether the interrupt is edge or level triggered > other than data sheets and through oscilloscope.
An interrupt control line (bit) is set, and remains set until the hardware that set the bit resets it. So, in a sense, all interrupts are "level". However, the old PC/AT interrupt controller latches this interrupt internally on the rising edge. Therefore, until the interrupt controller is 'acked' this bit will remain set even if the hardware has released it's control of the interrupt line. Latching of this bit makes sure that no interrupts are "lost". However, such edge-controlled interrupts don't allow sharing of an interrupt because new edges are not detected until both the controller has been 'acked' and the hardware stops driving the interrupt line.
To share interrupts, you need 'level' interrupts and the 8259 does not normally do level interrupts. There is an extended mode register to attempt to make it do level interrupts, but the rest of the hardware usually prevents this from being workable. More on this later.
> > 2. Can program PIC(Interrupt Controller 8259A)? >
For experiments, of course, you can do anything you wish . However, you do not want to mess with the software controlling the 8259 in the kernel. The kernel software takes care of everything for you. Your ISR is simply a 'C' procedure that the kernel will call when your hardware interrupt occurs. Therefore, you do not program or even touch the 8259.
> 3. If so how can I program PIC to set the mode as edge or level > triggered interrupt mode. >
The 8259 cannot be used with level interrupts. This is because when an interrupt line goes true, it is latched internally.
> 4. I want to have shared interrupts for two devices for which I need > have interrupts for the two devices as level triggered.So I want > to confirm whether the interrupt generated is level or edge > triggered . How can I confirm? > If it is edge triggered then Can I change to level triggered? >
Shared interrupts must be level interrupts. You must use the APIC to do this and, again, your software does not directly touch the APIC. The kernel will handle everything for you.
> 5. Data sheet of PIC tells that interrupt trigger mode can be > programmed . How can this be programmed? >
On some motherboards, there is an "extended mode" register at 0x4d0 and 0x4d1. The high address is for the second controller and the low address is for the first.
76543210 IRQ ||||||||_____________ 1 = level, 0 = edge |||||||______________ 1 = level, 0 = edge ||||||_______________ 1 = level, 0 = edge |||||________________ 1 = level, 0 = edge ||||_________________ 1 = level, 0 = edge |||__________________ 1 = level, 0 = edge ||___________________ 1 = level, 0 = edge |____________________ 1 = level, 0 = edge
Again, mucking with these registers will hang the machine.
Many driver-writers attempt to make things more complicated than they really are. Here is an ISR which only bumps an interrupt count. It executes when IRQ7 (the printer port) status bit gets hit. A function generator conected to this port will interrupt about 85,000 to 90,000 times per second without losing any interrupts. The printer port doesn't have to be 'acked' so there's nothing to do there. Your hardware probably has to be serviced to reset its interrupt request.
static void device_isr(int irq, void *p, struct pt_regs *regs) { INFO *inf = (INFO *) p; inf->intrs++; }
Note there are no instructions to program the interrupt controller(s). From a programmer's perspective, it's magic.
Cheers, Dick Johnson **** FILE SYSTEM WAS MODIFIED **** Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |