[lkml]   [2003]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] irq handling code consolidation, second try (ppc part)
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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