Joerg Dorchain (dorchain@wirbel.com)
Sun, 30 Aug 1998 12:59:29 +0200 (MET DST)
Andrea Arcangeli writes:
> On Sat, 29 Aug 1998, Philip Blundell wrote:
>
> >I wasn't thinking in terms of performance really. The current code is
> >certainly extremely ugly and could do with being changed. Having thought
> >about it more, Joerg's plan of having the lowlevel driver claim the interrupt
> >and call a function pointer to pass it to the higher devices sounds like the
> >way forward. Fortunately I don't think this will break the API seen by
> >high-level devices, even at the binary level, so we can safely make the change
> >during the 2.2 release cycle without upsetting people.
>
> I think it' s better to implement it now instead of wait the middle of
> 2.2.
My opinion, too.
>
> >
> >The gist of it was that on some hardware you need to perform a specific
> >acknowledge cycle when you handle an interrupt. (This is true up to a point
> >on the PC, but in that case the code in kernel/irq.c handles it -- apparently
> >on the Amiga it's a lot more visible to drivers.)
>
> If the irq chip ack it' s more visible it' s a bug in the amiga port. If
> it has to be more visible for some unknown reasons we must add a new arch
> specific API to the kernel and #define it {} for every other port.
No, it's not a bug, it's feature ;-). No, seriously, the Amiga had shared
interrupts right from the beginning, and an expansion architecture where
you can install almost every kind of hardware in. As far as interrupts
are concerned, it is thought like this (also in "native" AmigaOS): Some
chip on the card generates an interrupt, which somehow makes its way to
the CPU. The cpu start the OS's irq dispatcher. The dispatcher looks at the
level of the irq (on m68k similiar to the diffrent irq numbers on intel)
and calls a handler chain. This chain is a linked list of funtions that
get called in order when the interrupt occurs.
>
> And I don' t understand how changing the parport irq handling code would
> help workarounding this port bug (even if I agree for other reasons to
> change the code).
A device driver can register a irq-handler. The idea is that this works
with any kind of hardware, and only the driverneeds to know it. (In case
of the serial port, there is a plugin-card for the amiga that even has a
16550-chip on it, which is really strange compared to motorolas serial
chips designed for the m68k family, but it works.) On the other side,
only the driver know it's hardware, it can acknowledge the intrrupt (i.e.
tell the hardware that the irq is handled so it can stop signalling it.)
So the low-level driver has to handle the hardware specific part. That
is, when it gets called, it _may_ be its interrupt, or maybe some others
(on the amiga, the irq-level used for MFCIII expansion card is also used
by most scsi-adapters). So first check if the interrupt came from the
handled hardware, and if not, return as quick as pssible to let the next
handler try its luck.
The reason why the parport-driver for the built-in port works is that the
acknowdgement is done deciding which handler chain to call. the chip for
the parport can also generate interrupts for different reasons. But for a
plugin Ccard, the OS doesn't know anything about the hardware, only the
driver. For this reason you can run into troubles if you have a
plugincard activ when booting to linux without a driver for it. (For most
cards you have to activate it to generate interrupts, but if that was
done under AmigaOS....)
Joerg
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:09 EST