lkml.org 
[lkml]   [1998]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.053 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site