Andrea Arcangeli (email@example.com)
Sun, 7 Dec 1997 12:49:00 +0100 (CET)
On Sat, 6 Dec 1997, Linus Torvalds wrote:
>Why is dev_id NULL in the first place? It always makes sense to have some
>device ID, and you _have_ to have it if you expect to ever share
>interrupts (something that is fairly typical with parallell ports, I'd
Parallel ports don' t share interrupts.
The parallel port can share (really it don' t share but shedule) more
pardevice (in my case the ZIP parallel drive and the printer) because the
ZIP is able to connect the port ad disconnet. When the ZIP connect the
port, the printer lines should be in tre-state. So if the printer will
generate a interrupt while the ZIP is connected, that interrupt will be
missed. So the parallel port can' t share interrupt. Philip correct me if
I am wrong.
For this reasons when more pardevice are running at the same time, we can'
t use interrupt but we must revert to polling. This is easy for ppa (that
is always polled) but need some smarter code for lp. To speed and safe fix
the problem (to avoid deadlock) I first developed a patch that revert lp
to polling if more than one device was parport registered. Then I
developed another patch that allow lp to use interrupt all the time except
when it' s sharing the port with other device. Philip should apply my
latest patch in these days.
The patch allow also to change the priority of the printing. This is
important because without it, the sharing (that really is a sheduling)
result in a char printer, a ppa_scsi_command, a char printed... and this
_slow_down_ the printing.
>The patch looks ok, but the _reason_ for the patch is not clear..
The patch should be right, because dev_id is == NULL _only_ when the
interrupt function is foo_null_intr_func() that do nothing. Parport
architect used this "null" function to see parport%d as the owner of the
port->irq in /proc/interrupts when no pardevice are using it.
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- 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:17:10 EST