On Sun, 13 Mar 2011, Sam Ravnborg wrote: > Hi Daniel - thanks for looking at this patch. > > I was actually planning to send it to David tonight. > But after your comments I will wait. > > > I have begun too look at the patches, one thing that strikes me is > > why handle_level_irq is used and why the ack functions irq_ack and > > irq_mask_ack are not defined. > > The sun4m at least uses level triggered interrupts. > And looking at the implmentation the enable() and disable() functions > in all cases did a simple mask and unmask - also the leon variants. > > So based on this observation I decided to go got the handle_level_irq > flow handler. From the implmentation in kernel/irq/ I could > also see that handle_level_irq always called irq_mask() / irq_unmask() > which was a match towoards to earlier implemtnation. > > On top of this - this just worked for my sun4m box. > > > On the LEON architecture IRQs are > > normally edge triggered, the exception beeing PCI interrupts that is > > level triggered. Implementing the ack functions in the current > > implementation would result in acking edge triggered IRQs which means > > IRQs may be lost (on the LEON at least)? I thought SUN SPARCs also have > > edge triggered interrupts and that the CPU acks the IRQ automatically > > when the trap is taken? > > > > What is the difference between having handle_level_irq without ACKs > > implemented and having handle_edge_irq doing the interrupt flow > > handling? > > Thomas? Can you help here? You are much more into these details than I am. That largely depends on the hardware. There is hardware which automatically acks either on trap entry or with the mask. Also edge triggered interrupts can be handled entirely safe by handle_level_irq if the hardware latches the edge even when the interrupt line is masked. W/o looking at the actual datasheets I can't tell. Thanks, tglx
