> "A month of sundays ago Peter T. Breuer wrote:"
> > OK - this one is simple.
> >
> > I use the PC speaker driver. It uses ACK_FIRST(0x01) (or whatever) in
> > a modification to irq.c. That is broken by the change to ACK_FIRST in
> > 2.0.15.
>
> I have now read the assembler in irq.h that ACK_FIRST(mask,nr) expands to in
> 2.0.24 ... It doesn't seem to use the new argument (nr) to ACK_FIRST (any
> longer?. So the guy who
> plugged in 0 for the new argument in the call to ACK_FIRST in irq.c should
> have been right - but he reports that that functions wrong. Is the whole PCSP
> inclusion in irq.c just horribly broken by the changes since 2.0.0?
What happened (I believe - just from what I can remember - this is
not necessarily true!) was that a patch called something like irqtune was
bandied around that was supposed to make things like serial stuff better
and quicker or something. This was integrated into 2.0.15, changed in
2.0.17, 2.0.18 and removed in 2.0.19 (due to some complaints!).
The whole idea ( I think) was to do Specific End of Interrupts
(EOI) to the PIC interrupt controller, rather than Non-Specific EOIs. This
involved passing the number of the interrupt to the macro, so it could
form the right Specific EOI.
When the idea got shelved (at 2.0.19), presumably Linus left in
the passing of the interrupt number, as it was supported elsewhere, and
made future changes to irq.h easier. (And the back-out patch smaller)
What the status (working, useful or otherwise) of the irqtune
patch is, I don't know.
>
> (and who in hell did that in a stable kernel release series :-).
Quite!
>
> Any assembler experts out there like to rewrite the PCSP irq.c code? I'll be
> happy to send it to them!
I'll have a go if you want, but don't count on me knowing what I'm
doing....
-- Peter Denison <peterd@pnd-pc.demon.co.uk> Currently (still) working on a driver for Promise cards under Linux.