[PARPORT] lp and interrupt


Andrea Arcangeli (arcangeli@mbox.queen.it)
Wed, 15 Apr 1998 02:24:45 +0200 (CEST)


1. nIRQ bit in the status port (not used now).

Now we consider the port ready if ACK is low or BUSY is high. This should
be right. In that cases we don' t interruptible_sleep_on(). I read in
parallel.pdf at http://www.senet.com.au/~cpeacock/parallel.htm that exists
another field to check, in order to know if the port has just generate
an interrupt:

------------ quote from the doc --------------------
Base + 1 Status Port Read Only Bit 7 Busy
Bit 6 Ack
Bit 5 Paper Out
Bit 4 Select In
Bit 3 Error
Bit 2 IRQ (Not)
^^^^^^^^^^^^^^^
Bit 1 Reserved
Bit 0 Reserved
Table 5 Status Port

The Status Port (base address + 1) is a read only port. Any data written
to this port will be ignored. The Status Port is made up of 5 input lines
(Pins 10,11,12,13 & 15), a IRQ status register and two reserved bits.
Please note that Bit 7 (Busy) is a active low input. E.g. If bit 7
happens to show a logic 0, this means that there is +5v at pin 11.
Likewise with Bit 2. (nIRQ) If this bit shows a '1' then an interrupt has
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
not occurred.
^^^^^^^^^^^^
------------ quote from the doc --------------------

According to the M$ ECP specs at http://www.fapo.com/files/ecp_reg.pdf the
bit 2 should be considered reserved as bits 0 and 1.

I noticed that my printer say always bit 3 ==1 and works fine while your
one Philip say always bit 3 == 0 so the interrupt should be just
happened according the docs and you see the stall.

I think that not all parallel port can handle that nIRQ bit so using it
can result in a mess.

2. LP_PINTEN.

It seems that LP_PINTEN doesn' t work for you Philip. Your parallel port
seems to continue to generate interrupt even if LP_PINTEN is _not_ set in
the control port. I think that these problems could be hardware related.
Can people tell me which printers don' t work with 2.1.95 lp so I can try
to find one between these printers to try it out myself?

I see also that we run:

        w_ctr(minor, LP_PSELECP|LP_PINITP|LP_PINTEN);
        status = r_str(minor);

in this order. It would be nice if somebody is having troubles can test if
running it in the reverse order could help. Maybe writing the control
register could make instable the status register for a while?!?

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