Messages in this thread | | | Date | Mon, 9 Feb 1998 22:51:41 +0900 | From | NIIBE Yutaka <> | Subject | [PARPORT] Re: problems with parallel port IRQ detection |
| |
Philip Blundell writes: > The PLIP in 2.0 didn't actually probe for IRQs, it just guessed > on the basis of the port address.
Just for records,
The implementation of PLIP in 2.0 *probes* for IRQ for some special parallel ports. At least, it probed the IRQ of my (old) notebook PC when it's connected. Yes, it doesn't work for Standard Parallel Port.
Here is the reason why it detect IRQ of my (old) notebook:
There were optimized implementations of the parallel port, which does: ___ INTERRUPT_REQUEST = !IRQ_ENABLE | ACK ___ With this circuit, interrupt is requested on the positive edge of ACK, when IRQ_ENABLE = 1. Correct (standard) behavior is one-shot with the ___ edge of ACK.
Here is time chart, where INT(S) is standard INTERRUPT_REQUEST and INT(O) is the INTERRUPT_REQUEST of the optimized implementation.
===================================================== ______ ____ ____ ____ _______ ENABLE ____ ____ ____ ____
_______ __ __ ____ __ __ __ ______ -ACK __ __ __ __ __ __ __
===================================================== _ _ _ INT(S) _____________ _____________ _______ _____
___________ _________ ___ __ ____ ______ INT(O) __ _ _ _ _ o x o x o =====================================================
In three cases (marked as "o"), INT(O) emits correct edge as INT(S) does. In two cases (marked as "x") INT(O) emits bogus signals, but if the usage is limited for printer, these cases never occur.
With old memory of my notebook "Nomad", -- NIIBE Yutaka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |