lkml.org 
[lkml]   [2003]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: irq consolidation
On Sat, Jun 07, 2003 at 02:48:03PM +1000, Anton Blanchard wrote:
> We are hoping to kill irq_desc[NR_IRQS] completely and instead allocate
> them on demand with some sort of hash to map an interrupt number to an
> irq_desc.

The same thought has crossed my mind as well for ARM; the hardware
interrupt controllers are becoming more inteligent, and there is
the possibility that system designers will mix inteligent interrupt
controllers with standard types.

Also on ARM, we're currently defining NR_IRQS on a per-platform class
and even a per-platform basis.

I've been wondering whether we even need to think about passing some
alternative identifier of an IRQ line around, instead of a number.

> Im working on top of Andrey Panin's irq consolidation patches
> in the hope that it goes in first and other architectures can benefit
> from these changes (I think SGI's ia64 boxes have similar issues as
> well as large x86)

I believe Andrey's IRQ consolidation provides a single flat IRQ
structure. Unfortunately, this doesn't reflect the reality that we
have on many ARM platforms - it remains the case that we need to
decode IRQs on a multi-level basis.

Given the rate which ARM has progressed and evolved during the existing
2.4 lifespan, it doesn't make much difference to us whether these
changes happen now or later. If it happens later, it will be during
the 2.6 series of kernels, so "now" is preferable. Reality is such
that ARM hardware moves a hell of a lot faster than x86 hardware.

--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.041 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site