> Hi, folks
> I am hacking the source kernel recently, I found when IRQ is
> triggered, Linux kernel always *BLOCK(or MASK)* the IRQ and UNBLOCK it
> after the IRQ has been called. I wonder why IRQs should always been
> BLOCK first even in fast_IRQ? Can anyone help me?
>
The interrupt controllers have an "in-service latch", which allows them
to capture short transients. Basically, these latches are how the
controllers "remember" that an interrupt occurred.
The input to these latches come from gates. When you mask-off an
interrupt, you disconnect the input of the in-service latch from
the interrupt line (the trace on a PC board) using a gate. This allows
you to reset the in-service latch while the interrupt line is still
active.
The reseting of the in-service latch is the so-called "ACK" in
the code.
Interrupts, either edge or level, work like this:
(1) Hardware has a condition requiring CPU service and raises
the interrupt request line.
(2) The controller(s) latch this event in the in-service latch,
one for each level.
(3) The controller(s) priortize the event and, when the interrupting
devices' turn comes, the interrupt line to the CPU is made active
Note that the CPU has only two interrupt lines, the maskable
(controlled with cli/sti) and the unmaskable, which can't be
ignored by the CPU (can be turned off using hardware).
(4) A special bus cycle occurs similar to a DMA bus cycle, where
the interrupt number is shifted to produce an index into
the interrupt table or GIDT (global interrupt descriptor table).
(5) The kernel's common interrupt code eventually gets control and
the kernel sets up an environment where the interrupt can
be handled with ordinary 'C' code. This includes saving the
interrupted process context, making data addressible, providing
a stack, etc.
(6) The kernel then masks off the interrupt line (which is still active)
so it can reset the in-service latch (which would allow another
interrupt to be "remembered").
(7) The kernel then calls "your" interrupt service-routine code.
(8) Your code is supposed to handle the needs of the hardware so that
the hardware drops its interrupt request. If your interrupt
service routine doesn't do this, it is broken.
(9) Once the needs of the hardware are done, the ISR code returns to
the common kernel code. The kernel re-enables the interrupt by
unmasking the input. If your hardware has raised its interrupt
line again, this will be "remembered" by the in-service latch
so interrupts are never lost.
(10) The kernel restores interrupted context (or another), and the
machine is ready for the next interrupt.
This is how it is supposed to work. Interrupt service routines should
be concerned only with the specific hardware they service. They should
never touch the interrupt controller(s) or the APIC interrupt hardware.
Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.108 on an i586 machine (66.15 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.altern.org/andrebalsa/doc/lkml-faq.html