Messages in this thread | | | From | Neil Brown <> | Date | Sun, 30 Apr 2006 14:48:43 +1000 | Subject | Re: better leve triggered IRQ management needed |
| |
On Saturday April 29, torvalds@osdl.org wrote: > > > On Sat, 29 Apr 2006, Alan Cox wrote: > > > > Trying to guess the current IRQ level v edge on a PC is very hard. > > Trying to set it correctly from the driver is rather easier. > > I disagree. It's not any easier at all. > > On PC's (x86 and x86-64) we actually already set the ELCR as well as we > can (look for "eisa_set_level_irq()"). And a driver _literally_ cannot > change it from the system value, because of the polarity confusion. > > In the other cases (IO-APIC) we usually have it level, but when we have it > marked as an edge, there is almost always a real reason for that too (ie > legacy interrupt, it really _is_ edge-high, not level-low).
So what do you propose should be done to better handle such poorly built machines?
As a concrete example I have a notebook which definitely assigns shared interrupts to IRQ-10 (See /proc/interrupts below) yet the ELCR only flags IRQ-11 as being level triggered and the rest are edge triggered. And with this configuration I definitely lose interrupts to the wireless ethernet (ra0).
How do I make this work reliably? I could:
1/ modify handle_IRQ_event so that it is more resilient to the possibility that shared interrupts are edge triggered. This can be done be iterating over all action->handlers until they all return IRQ_NONE.
2/ Arrange that the ELCR bit is set for any IRQ for which a shared interrupt is registered (on the basis that the code for handling shared interrupts is not resilient against them being edge triggered).
3/ Have a kernel parameter, or sysfs variable, or magic write-to-/proc/interrupts of something that allows the ELCR to be read and set, and leave it up to user-space to perform the risky task of fiddling with ELCR
4/ As userspace can do inb/outb itself simply leave it all to userspace to worry about.
5/ Something I haven't thought of.
I don't much care which (those 2 seems best based on my limited understanding) but I would be good to know how you think this should be handled so that progress can be made.
Thanks, NeilBrown
CPU0 0: 180230371 XT-PIC timer 1: 91 XT-PIC i8042 2: 0 XT-PIC cascade 4: 10 XT-PIC serial 8: 4 XT-PIC rtc 10: 3812362 XT-PIC yenta, yenta, ohci_hcd:usb2, ohci_hcd:usb3, ehci_hcd:usb4, ra0 11: 0 XT-PIC uhci_hcd:usb1 12: 3290 XT-PIC i8042 14: 63804 XT-PIC ide0 15: 37 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |