Re: [RFC] irq handling code consolidation, second try (ppc part)

Benjamin Herrenschmidt (benh@kernel.crashing.org)
05 Jan 2003 23:03:20 +0100


On Sun, 2003-01-05 at 20:05, Linus Torvalds wrote:
> On 5 Jan 2003, Benjamin Herrenschmidt wrote:
> >
> > Note that if we go the full way abstracting interrupts, then the
> > interrupt "tree" should be separate from the device tree. The interrupt
> > "parent" of a device may not be (and is not in a whole lot of cases I
> > have to deal with on pmacs and embedded) the "bus" parent of a given
> > device.
>
> I disagree. The pmac braindamage is a pmac problem, and not worth
> uglifying the generic device layer over. Besides, as far as I know, it is
> trivially solved by just making the pmac irq controller be a root
> controller, and that's it. There are no other irq controllers there that
> are worth worrying about.

Right, though some other machines (CHRP for example) with cascaded
legacy 8259 on top or below OpenPIC may also want more flexibility
regarding interrupt routing.

It seems quite common (at least it is in embedded world) to actually
wire interrupt sources rather randomly to the closest device than can
act as an interrupt controller regardless of the actual bus layout ;)

But I agree this can be solved by defining the "main" PIC as root
controller regardless of it's actual bus location.

> > Do you think this is still 2.5 work ?
>
> No.

Makes sense. Though the simple tweak of allocating more irq_descs in the
existing array (by slightly extending the array) may be worth trying for
fixing some of the pcmcia problems now. I need to experient more, it
might actually be enough to just disable IRQ routing on the pcmcia
bridge when the slot is shut down.

Ben.

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