Philip Blundell (philb@gnu.org)
Sat, 29 Aug 1998 22:17:21 +0100
[nb. I trimmed the Cc: list]
>>Arguably a better way to do this would be to have the parport code claim the
>>interrupt directly, and just call the function for the appropriate driver.
>
>Yes agreed, this would be a cleaner and more efficient way but I am not
>sure how much it would it improve performance due the fact we are just
>very clever avoiding not needed parport_sharing switch so I agree that is
>not a change _needed_ for 2.2.
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.
Basically the way it would work would be that all the irq handling gunk would
come out of parport_share.c; the lowlevel driver would claim interrupts as
necessary and just do (port->cad->irq_func)(...port->cad->private...) to pass
the interrupt up.
>I can' t find the first email of this thread...
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.)
At the moment the lowlevel driver is pretty much out of the loop as far as
interrupts are concerned and so this is rather tricky to handle.
p.
-- 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