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
needed.
> > > + 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
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
