Re: [PARPORT] parport irq handling v2


Alan Cox (alan@lxorguk.ukuu.org.uk)
Mon, 31 Aug 1998 17:09:02 +0100 (BST)


> Excuse me Alan, I can' t understand again :-( and I don' t understand the
> differences between library and mid level driver very well :-((.

Midlevel driver Library

        kernel kernel
          | |
          V V
       parport driver
          | |
          V V
       driver support code

> parport_pc_irq() parport_ax_irq() but I can' t see real advantages. It
> would be less clean I think.

Yep now I've followed the code its a bit more sane than I first thought

> In my patch parport_irq() does something like:
>
> parport_irq(port)
> {
> if (parport_examine_irq(port))
> return;
> else
> port->cad->irq_func(port->cad->private);
> }
>
> Really in parport_irq() there is some spinlock stuff and other checks.
> Plus, with PARPORT_OTHERS not #def, the asm code is the equivalent of:

Surely its up to the hardware specific driver to check the irq and called
parport_irq(port) if it decides there is an IRQ pending (indeed it may be
just an inline to do port->cad->....)

> If I am really out please tell me and I' ll stop everything waiting for
> the right code at least to understand what I can' t understand with
> only (English) words ;-).

No no don't do anything like that. Im arguing over future semantics not
that parport doesnt currently work. "Works" is far more important than
most other issues 8)

Alan

-- 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:12 EST