Subject: plat_irq_dispatch

From: Chris Rhodin <[email-masked]>
Date: Fri, 20 Feb 2009 00:33:09 -0800

Hi,

I've been digging through the interrupt code trying to figure out what 
would be required to make it "generic irq" clean.  I have a couple of 
questions that I haven't been able to answer myself.

1) I count 24 different versions of plat_irq_dispatch, many of them only 
seem to vary in the use and priority of the 8 sources in the cause 
register.  Is this really the case or am I missing something subtle?

2) Why isn't plat_irq_dispatch looping until all active interrupts are 
serviced?

I already have what I believe is a generic plat_irq_dispatch that finds 
the highest priority irq in (almost) constant time.  It needs one block 
of defines to identify the 8 sources and another block to set the 
priorities.

Thanks,

Chris Rhodin

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 20 Feb 2009 13:47:29 +0000

> register.  Is this really the case or am I missing something subtle?

No, you're correct.  Part of why all these plat_irq_dispatch versions
do exist is that there are different versions of CPU interrupt controllers.
There is the basic MIPS CPU integrated interrupt controller providing
6 level-sensitive inputs and 2 software interrupts.  Some processors
such as the RM7000 processors and E9000 cores extend this in vendor-
specific ways.  Outside of the actual processor in most cases there is
a system-specific hierarchy of interrupt controllers attached which
needs to be polled in software to find the source of a pending interrupt
and compute an interrupt number for use by the generic code.

plat_irq_dispatch came into existence in commit
5476b529ad3ba9db6e189c79d692d2929c1d1f95 as the hardware-specific part
of the former platform-specific handle_int family of functions and for
sanity reasons is written in C, no longer assembler.

> 2) Why isn't plat_irq_dispatch looping until all active interrupts are  

The assumption is that most often there won't be another interrupt
pending and that it is faster on average to just take another interrupt
exception than to always perform the check.

> of defines to identify the 8 sources and another block to set the  

I'm not sure how important priorities actually are these days.  In the dark
past of Linux the SCSI code did go braindead if timer interrupts were not
handled at higher priority than device interrupts.  That's got fixed
eons ago.  Some embedded devices may have requirements there?

  Ralf