Andrea Arcangeli (arcangeli@mbox.queen.it)
Mon, 31 Aug 1998 16:58:46 +0200 (CEST)
On Mon, 31 Aug 1998, Alan Cox wrote:
>The low level drivers should be allocating the IRQ and probing for it.
I don' t understand very well. With my patch the irq will be requested and
freed only for one time and _only_ by the lowlevel driver in the
parport_claim_resources() callback. The lowlevel driver continue to probe
for the irq as usual then at resource allocation time
parport_claim_resources() will check the output of the probe looking for
port->irq and will request_irq() if needed.
>If parport provides a utility parport_irq_probe_helper all well and good
>but its not appropriate to force its use
>
>This is the "library/mid level" driver thing.
Excuse me Alan, I can' t understand again :-( and I don' t understand the
differences between library and mid level driver very well :-((.
I can tell you that I can move the parport_irq() handler in
parport_pc_irq() parport_ax_irq() but I can' t see real advantages. It
would be less clean I think.
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:
parport_irq(port)
{
port->cad->irq_func(port->cad->private);
}
So I can' t see one valid reasons to duplicate this irq code in the
lowlevel drivers (except for which where examine_irq() is implemented and
so the additional call to examine_irq() could be avoided moving
parport_irq in parport_amiga_irq() but that call should be not performance
critical I think).
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 ;-).
Andrea[s] 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 30 Dec 1998 - 10:18:11 EST