Re: better leve triggered IRQ management needed

[Neil Brown]

On Saturday April 29, torvalds@xxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/