On Saturday April 29, [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
