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

[Jun Sun <jsun@mvista.com>]

On Mon, Dec 16, 2002 at 02:44:38PM +0100, Maciej W. Rozycki wrote:
> On Sat, 14 Dec 2002, Ralf Baechle 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. 
> >

I actually meant to read IRR.

I had the code for a while.  I remembered I was reading a i8259 programming 
guide which recommands this method (perhaps for that MIPS board, which should
generally apply to other MIPS boards.).  The idea is to read IRR to figure 
out which interrupt you want to service and directly ack it and mask it.

This style fits more or less what we are doing with the rest of IRQ handling.

> > 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?
> > Probably.
> 
>  Definitely -- the only place the IRR is used is the Neptune (i82378IB/ZB
> SIO, i82379AB SIO.A or i82374EB/SB ESC; one or more of them -- the note in
> arch/i386/kernel/time.c isn't detailed enough) i8254 core latch
> malfunction workaround.  This is needed for do_slow_gettimeoffset(), which
> we do not need as we use the processor's internal timer for getting the
> offset (or are there any R3k-class systems with an Intel-style chipset?). 

I don't think so.

> Even if we needed do_slow_gettimeoffset(), 

No MIPS boards are using do_slow_gettimeoffset().  We really should get
rid of it.

>  BTW, I thought on the code a bit and I discovered a few potential
> problems due to races.  Handling them depends on the way acks are sent to
> i8259s -- Jun, could you please elaborate?
>

I am not sure which part you are referring to.  The dispatch_i8259_irq() itself
is called from the first-level interrupt handling routine (assembly or in C),
running with interrupt disabled.

When you decide to service an i8259 IRQ, you move on to call do_IRQ(), still
with interrupt disabled.  Pretty early in do_IRQ() we will do an ACK which will
clear the bit in IRR, before possibly later we turn on interrupt again.


Jun