Andrea Arcangeli (arcangeli@mbox.queen.it)
Wed, 1 Apr 1998 16:05:49 +0200 (CEST)
On Wed, 1 Apr 1998, Tim Waugh wrote:
>Hi,
>
>The behaviour of the printer driver has changed between 2.0 and 2.1 in
>that it now defaults to being interrupt-driven if parport can find out the
>IRQ to use. It's been suggested that this is a bad thing, since it can
>cause clashes that previously would have caused no harm.
If the parport lowlevel driver will autodetect the right irq I don' t see
how can it cause an harm. I don' t see the problem how lp specific but
instead as parport_lowlevel specific. If lp will cause an harm every other
pardevice that will use interrupt on the same parport will do the same.
>So, my plan is to utilise tunelp. lp defaults to polling until given a
I don' t like lp defaults to polling. If the parport_lowlevel driver will
no detect the irq (or it is not forced to use one) lp run polled just now.
>non-zero IRQ by tunelp -i. Then it uses whatever IRQ parport found, or
>returns -EINVAL if there was none. (Currently, tunelp -i will always
>get -EINVAL.)
Updating tunelp to work with the current lp is a good thing to do. We
could use -i and +i to disable/enable lp interrupt printing. BTW, In the
lp code we had to touch only the LP_POLLING() macro to take care of
another flag.
>It would also be good to have a module parameter to enable
>interrupt-driven operation from the outset. A kernel parameter would be
>good too, but I can't think of a good syntax for it (anyone?).
It would be nice but I don' t think it' s really needed. If somebody will
need to change the default settings can add:
post-install lp tunelp /dev/lp? -/+i
to /etc/conf.modules if lp is a module, or can run it at boot time (maybe
we could tell this in the parport docs when tunelp will work).
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:17:34 EST