Re: [RFC] killing the NR_IRQS arrays.

On Sat, 2007-02-17 at 02:37 +0100, Arnd Bergmann wrote:
On Friday 16 February 2007 23:37, Benjamin Herrenschmidt wrote:
You might want to have a look at the powerpc API with it's remaping
capabilities. It's very nice for handling multiple domain spaces. It
might be of some use for you.

I don't consider the powerpc virtual IRQs a solution for the problem.
While I believe you did the right thing for powerpc with generalizing
this over all its platforms, it really isn't more than a workaround
for the problem that we can't deal well with the static irq_desc
array.

It's not a solution per-se, though it contains elements of solution like
the reverse mappin, which I use to map HW numbers to virtual irqs but
can trivially adapt to map HW numbers to irq_desc pointers.

Among other things, I want to make sure that we don't end up with just
putting an irq number in a field of the irq_desc and have half of the
drivers peek at it and assume we can convert between irq_desc* and
number in arbitrary ways.

The HW irq number should be as much opaque as possible from the world
outside of the PIC code and/or arch code that assign them. That's an
area where the powerpc and/or sparc code might be of use.


When that problem is now getting worse on other architectures, we
should try to get it right on all of them, rather than spreading
the workaround further.

Yes, but I'd like aspects of my remapping work to be included in
whatever we come up with, which is to have the new irq_desc either hide
the underlying HW number, or at least associate it make it very clear
that it's an opaque token and not guaranteed to be unique accross
multiple PICs in the system.

In addition, if we remove the numbers, archs will need basically the
exact same services provided by the powerpc irq core for reverse mapping
(going from a HW irq number on a given PIC back to an irq_desc *).

Either using a linear array for simple PICs or a radix tree for
platforms with very big interrupt numbers (BTW. I think we have lockless
radix trees nowadays, I can remove the spinlocks to protect it in the
powerpc remapper).

Ben.


-
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/

Relevant Pages

  • Linux 2.6.19-rc2
    ... The irq thing turned out to be perhaps a bit more painful than ... Aside from those two things, we've got some arch updates (PowerPC, MIPS, ... s390 traps.c __user annotations ... fix misannotations in loop.c ...
    (Linux-Kernel)
  • Re: [RFC] killing the NR_IRQS arrays.
    ... exact same services provided by the powerpc irq core for reverse mapping ... (going from a HW irq number on a given PIC back to an irq_desc *). ... ISA the linux IRQ number is a hardware number. ... What you call the hardware interrupt ...
    (Linux-Kernel)
  • Re: [PATCH] sparse_irq aka dyn_irq v13
    ... On powerpc we have a mapping from virtual irq numbers (in the range 0 ... We use a value of 256 and I've been booting linux on 128 cpu sparc64 ... So keeping as much interrupt context close to the ...
    (Linux-Kernel)
  • Re: [i2c] [PATCH 19 3/5] Clean up error returns
    ... value 0 or -1 depending on the architecture, so your change is real on ... Since this driver didn't originally use the NO_IRQ ... Unless some platforms include an "empty" IRQ in their device ... We only get virtual IRQs in this code. ...
    (Linux-Kernel)
  • Re: [i2c] [PATCH 19 3/5] Clean up error returns
    ... Unless some platforms include an "empty" IRQ in their device ... We only get virtual IRQs in this code. ... Physical IRQ numbers are remapped and shouldn't be visible to drivers, ... that is 0 for arch/powerpc and -1 for arch/ppc. ...
    (Linux-Kernel)