"Randy.Dunlap" <rdunlap@xxxxxxxxxxxx> writes: > On Tue, 02 May 2006 07:52:22 -0600 Eric W. Biederman wrote: > >> Andi Kleen <ak@xxxxxxx> writes: >> >> > P.S.: There seems to be a lot of confusion about all this. >> > Maybe it would make sense to do a write up defining all the terms >> > and stick it into Documentation/* ? >> >> How does this look? >> >> I am pretty horrible when it comes to Documentation, >> but this seems to be the essence of what I was saying earlier. >> >> Eric >> >> >> diff --git a/Documentation/IRQ.txt b/Documentation/IRQ.txt >> new file mode 100644 >> index 0000000..5340369 >> --- /dev/null >> +++ b/Documentation/IRQ.txt >> @@ -0,0 +1,22 @@ >> +What is an IRQ? >> + >> +An IRQ is an interrupt request from a device. >> +Currently they can come in over a pin, or over a packet. > > No comma. Change packet to message? Sounds good. >> +IRQs at the source can be shared. > > Huh? That simple sentence confuses me. Should "source" really be > "sink" or "destination"? Or maybe say "IRQs at an interrupt controller > can be shared." Or is that too hardware-specific? > Anyway, what source is meant here? It doesn't mean that IRQs > at the producer device can be shared, right? It's more at the > consumer device where they can be shared. By source I was thinking at the irq controller pin. Interrupts are usually thrown from interrupt controllers to something in the chipset that interrupts the cpu, giving the cpu a token (ie an interrupt vector) that uniquely identifies which interrupt source threw the interrupt. Linux does not have generic infrastructure to allow two interrupt sources to share the same token passed to the kernel. In addition there are good reasons on some systems to change the token dynamically, (say to point the IRQ at a different CPU). So no generic code in the code should know about the token the cpu receives. The fact that msi.c actually knows about that token today makes is inflexible and maintenance problem. I guess I need to figure out how to work this additional information into my documentation then. >> +An IRQ number is a kernel identifier used to talk about a hardware >> +interrupt source. Typically this is an index into the global irq_desc >> +array, but except for what linux/interrupt.h implements the details >> +are architecture specific. >> + >> +An IRQ number is an enumeration of the possible interrupt sources on a >> +machine. Typically what is enumerated is the number of input pins on >> +all of the interrupt controller in the system. In the case of ISA > controllers >> +what is enumerated are the 16 input pins to the pair of i8259 > is >> +interrupt controllers. >> + >> +Architectures can assign additional meaning to the IRQ numbers, and >> +are encouraged to in the case where there is any manual configuration >> +of the hardware involved. The ISA IRQ case on x86 where anyone who >> +has been around a while can tell you how the first 16 IRQs map to the > awhile >> +input pins on a pair of i8259s is the classic example. Eric - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
