Andrea Arcangeli (andrea@e-mind.com)
Wed, 24 Feb 1999 14:50:01 +0100 (CET)
On Wed, 24 Feb 1999, Joerg Dorchain wrote:
>I understand the idea. In this case weīd better remove the handler
>completely (free_irq()) instead of brute-force disabling.
Read irq.c and then you'll see why I used disable_irq(). disable_irq()
does only a `decl' over a 32 bit variable in memory, free/request_irq()
does something more ;).
>I also donīt like the idea of having a mid- or highlevel function caring
>about hardware things like irqs. They donīt know about the specific
Fine.
>> is automagically done in the parport_pc only saving/restoring the control
>> port.
>
>I would consider this a side effect of PC-ish hardware. When I wrote the
>amiga parport drivers, I found it quite confusing that the irq-mask was
>in the same register as the control lines.
>
>How about documenting the semantics clearly?
The new semantic implicit in my latest patch I sent to the list yesterday
is that save_state and restore_state lowlevel operations has to care to
save/restore also the irq masking details of the hardware.
>This is currently done automatically for m68k-ports. Here, request_irq()
>also enables the irq-level. (When you register an irq-handler, you
The same is true for x86.
>BTW, what do I have to do to get the sources for m68k into the parport
>development tree?
You must sent them to Tim I think. He is releasing the latest parport
snapshots.
Andrea Arcangeli
-- 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 24 Feb 1999 - 09:01:37 EST