Re: [PARPORT] disable/elable_irq() in parport_claim/release().

Joerg Dorchain (
Wed, 24 Feb 1999 15:47:22 +0100

On Wed, Feb 24, 1999 at 02:50:01PM +0100, Andrea Arcangeli wrote:
> On Wed, 24 Feb 1999, Joerg Dorchain wrote:
> 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 ;).

Yes, as I said, I understand the idea. Unfortunately this contradicts
very hard with shared interrupts. request_irq and free_irq are more
expensive (in terms of executed instructions), but that may be bearable
if you exspect many unnessary interrupt.
> >
> >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.

Fine for you - donīt do neglect the fact that there is other hardware
lying around than a pc parallel port chip for which not everyone has the
docs ready?

Itīs a bit drastic to introduce these thing "implicitly", better express
it explicitly.

> You must sent them to Tim I think. He is releasing the latest parport
> snapshots.

I talked to him. Thank you for the hint.


-- To unsubscribe, send mail to: --
-- 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:50:31 EST