Re: [RFC][PATCH] Document what in IRQ is.
- From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
- Date: Wed, 03 May 2006 20:48:27 -0600
"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 hardwarecontrollers
+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
+what is enumerated are the 16 input pins to the pair of i8259is
+interrupt controllers.awhile
+
+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
+input pins on a pair of i8259s is the classic example.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision
- From: Brown, Len
- Re: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision
- From: Andi Kleen
- [RFC][PATCH] Document what in IRQ is.
- From: Eric W. Biederman
- Re: [RFC][PATCH] Document what in IRQ is.
- From: Randy.Dunlap
- RE: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision
- Prev by Date: Remove silly messages from input layer.
- Next by Date: Re: i386/x86_84: disable PCI resource decode on device disable
- Previous by thread: Re: [RFC][PATCH] Document what in IRQ is.
- Next by thread: Re: [(repost) git Patch 1/1] avoid IRQ0 ioapic pin collision
- Index(es):
Relevant Pages
|
Loading