[Top] [All Lists]

Re: [PATCH] add dispatch_i8259_irq() to i8259.c

To: "Maciej W. Rozycki" <>
Subject: Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: Ralf Baechle <>
Date: Sat, 14 Dec 2002 05:18:51 +0100
Cc: Jun Sun <>,
In-reply-to: <>; from on Sat, Dec 14, 2002 at 01:55:53AM +0100
Original-recipient: rfc822;
References: <> <>
User-agent: Mutt/
On Sat, Dec 14, 2002 at 01:55:53AM +0100, Maciej W. Rozycki wrote:

>  OCW3 defaults to IRR in our setup (as it does for the chip itself after
> writing ICWs) -- you need to select ISR explicitly before reading and
> reset it afterwards to avoid surprises.  Unless we change the default for
> MIPS, which seems feasible -- we don't have to handle i386 oddities like
> I/O APICs and weird chipset bugs.  And we avoid the need to grab a
> spinlock here.  Alpha went this path. 

We don't have I/O APICs but there's a bunch of MIPS boxes that are based
on Intel chipsets plus glue logic so we may have to deal with some of the
same kind of bugs.  And I'd not be surprised if the 8259 VHDL are coming
from the same source as the x86 ones so because I didn't want to tickle
the dragon's tail so I simply recycled the x86 code.  Overly defensive?

> > +           atomic_inc(&irq_err_count);
> > +   } else {
> > +           do_IRQ(irq,regs);
>  And how about using an offset passed from a user?  We're not on a PC --
> i8259 IRQs do not have to start from 0.  E.g. I find cleaner allocating
> CPU IRQs first if handled.

There's still ISA drivers out there with hard coded interrupt numbers.
That's why we assume that ISA / i8259 interrupts are 0 ... 15.  Doesn't
legacy stuff suck ...


<Prev in Thread] Current Thread [Next in Thread>