[PATCH] ARM: Allow machine to specify it's own IRQ handlers at run-time

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Dec 06, 2010 at 02:12:54PM +0800, Eric Miao wrote:
> On Sun, Dec 5, 2010 at 5:23 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Nov 22, 2010 at 04:26:50PM +0800, Eric Miao wrote:
> >> I wonder if it's still acceptable for a patch like below to have a dynamic IRQ
> >> handler at run-time. There is some changes to the irq_handler, esp. some
> >> SMP changes.
> >>
> >> Magnus had some similar patches to have a run-time irq_handler, which is
> >> a bit more complicated, but I'm also very happy with.
> >
> > I'd prefer a simple but efficient approach. ?I am worried about
> > unnecessarily increasing the IRQ latency - and IRQ latency is something
> > that we should be concerned about. ?It has the ability to make platforms
> > useless.
> >
> > Eg, we know that SMC91x net interfaces are sensitive to IRQ latency, and
> > the same is true of serial ports with small FIFOs.
> >
> > Any attempt to support multiple IRQ handlers is going to increase IRQ
> > handling latency - I don't think that's something which can be avoided,
> > and I'm wondering what effect this and the recent genirq changes is going
> > to have. ?Has anyone been keeping an eye on IRQ handling latency?
> >
> > Lastly, this patch is dependent on your machine class patches, which makes
> > it unsuitable as-is for mainline.
> >
> 
> This one isn't. I've rebased this on top of v2.6.37-rc1.
> 
> >> +#ifdef CONFIG_MULTI_IRQ_HANDLER
> >> + ? ? handle_arch_irq = class ? class->handle_irq : NULL;
                             ^^^^^^^^^^^^^^^^^^^^^^^^^