[Top] [All Lists]

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

To: Jun Sun <>, Ralf Baechle <>
Subject: Re: [PATCH] add dispatch_i8259_irq() to i8259.c
From: "Maciej W. Rozycki" <>
Date: Mon, 16 Dec 2002 14:44:38 +0100 (MET)
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
Reply-to: "Maciej W. Rozycki" <>
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. 
> 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?). 
Even if we needed do_slow_gettimeoffset(), I don't think anyone uses any
of these chips in a MIPS system (please correct me if I'm wrong) and the
workaround isn't implemented. 

 Some Alphas do actually use the i82378ZB SIO component, but they use a
processor's internal timer, too so they don't use do_slow_gettimeoffset()
and don't implement the workaround either.

 Surprisingly, there are no known i8259 core implementation bugs. 

 BTW, the workaround probably need not use the IRR -- the Read-Back i8254
command can be used to get the output state.  It's even possible with the
read-back command the latch for the counter would work correctly, so no
workaround would be needed at all.  The code is ancient, though, and
changing it would be tough -- a tester with a buggy system would be

> > > +         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 ...

 Ah, I see.

 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?


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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