Erik Mouw wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, Jul 18, 2007 at 08:43:40AM +0200, hinko.kocevar@xxxxxxxxxxxx wrote:
It is the job of the interrupt controller to take several physical lines,
or PCB traces if you wish, each leading to *only* one device and multiplex
those lines so that operating system sees them on a single IRQ number.
Not completely true. With the x86 and the original PIC (programmable
interrupt controller), the PIC takes 8 interrupt sources and mixes them
to the single interrupt line the CPU has. When the CPU acknowledges the
IRQ to the PIC, the PIC puts the number of the IRQ line on the address
bus so the CPU knows which ISR to call. The PIC could also prioritise
the interrupts, so that for example IRQ 0 (the timer) would get
priority over the other interrupts.
By using a wired or (pull-up resistor on the interrupt line with each
device an open collector output to pull the line down) you could share
a single IRQ line, but unfortunately the ISA bus wasn't designed that
way so you couldn't share interrupts. However, the PCI bus was designed
with sharing IRQs in mind: it has 4 lines (PIRQ1 through PIRQ4) that
are usually daisy chained to the PCI slots (for ASCII art, see
Documentation/i386/IO-APIC.txt). How PIRQ1-PIRQ4 are wired to the PIC
is another story, there could be another level of indirection,
important is that the BIOS should provide a list how it is done.
I'm not quite familiar with the way i386 works so this explanation is
greatly appreciated.
When two or more devices share an IRQ line, the kernel calls the first
ISR for that line. When the first IRQ returns IRQ_HANDLED, the kernel
won't call the ISR for the second device until one ISR returns
IRQ_HANDLED.
I'm not quite sure I understand this. I had the impression that if (with
shared interrupt lines) one interrupt routine exits with IRQ_HANDLED
interrupt is considered handled by the kernel (set aside the procedure
to disable the interrupt in the device itself). Only when certain
interrupt routine returns IRQ_NONE another interrupt routine can then
try to service the same pending interrupt!?!?
For example take LX100 etrax CPU [1] (which I'm familiar with) that has
eight physical pins - grouped together in a port called port A. Each pin of
port A can be used as interrupt source and can connected to a different
device. OS OTOH sees complete port A (8 all pins) on a single IRQ number
11. In order to assert which device caused the IRQ11 one needs to inspect
interrupt status register of port A and its bits to determine which device
actually caused the IRQ11. Several devices can assert the IRQ11 at the same
time and once all the set bits in interrupt status register have been
cleared all the devices have been handled.
That's a strange way. I've seen similar hardware on an ARM platform,
but there the 8 lines to port A are mapped to some high IRQ number (40
and up, IIRC). The kernel IRQ core code takes care of figuring out
which exact ISR to call and setting and clearing the bits in the status
register.
There are even stranger things on cris architecture than this 'manual'
interrupt handling. I have to fiddle with several interrupt status
registers and the port A pin status register itself to detect the pin
number that is active, possibly disable the line do the work and
re-enable the line when interrupt routine ends. I guess nobody bothered
to make this more abstract, like on ARM.
regards,
hinko
--
ČETRTA POT, d.o.o., Kranj
Planina 3
4000 Kranj
Slovenia, Europe
Tel. +386 (0) 4 280 66 03
E-mail: hinko.kocevar@xxxxxxxxxxxx
Http: www.cetrtapot.si
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
