-----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. 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. > 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. Erik - -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGnhS3/PlVHJtIto0RAv4tAJ0XM442XyMAiXfz8XpWKm/kLfPvnQCcCMLR ghdcRGwYQG+lDAqQEKwSPKg= =EbXt -----END PGP SIGNATURE----- -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
