Does anybody have a view on this?
------- Forwarded Message
Date: Sun, 25 Feb 2001 18:08:42 +0100
From: Johannes Lode <johannes.lode@gmx.net>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.0.33 i586)
X-Accept-Language: de, en
MIME-Version: 1.0
To: Philip.Blundell@pobox.com
Subject: PLIP int fix
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Dear Phil,
the PLIP driver is still not yet working out of the box. Probably you
are aware of that or not.
In good old version-1.2.13 times of the kernel I did some investigation
on that problem using the plip.com sources from Russel Nelson and some
test equipment like an oscilloscope. Since these days I'm using a little
patch to the kernel tree, that makes the plip.c working on my PCs.
The problem is, that the interrupt at the far end of the plip cable
isn't triggerd correctly. The trigger edge or the level is mixed up.
After some unsuccesfull tries of reprogramming the plip.c (I'm hardware
developer with little C programming experience and good ASM knowledge) I
decided to generate just a small pulse to trigger the remote rx
interrupt. The patch below does that for me.
The first patch is appliable for sure to the kernel trees 2.0.30 through
2.0.36 and also to 2.2.17 (where I took the diff from). Although I'm
using this modification already since the 1.2.13 kernel in this way
without any problems. The second patch applies to the 2.4.1 kernel and
is not tested yet, but should work.
this is the patch for 2.2.17:
/********************* cut here ****************/
--- drivers/net/plip.c.orig Thu May 4 02:16:41 2000
+++ drivers/net/plip.c Sun Feb 25 17:12:12 2001
@@ -751,8 +751,10 @@
if ((inb(PAR_STATUS(dev)) & 0xf8) != 0x80)
return HS_TIMEOUT;
- /* Trigger remote rx interrupt. */
- outb(0x08, data_addr);
+ /* Trigger remote rx interrupt using a pulse */
+ outb(0x08, data_addr); /* this *may* generate an
interrupt on some broken remote parport hardware */
+ udelay(PLIP_TRIGGER_WAIT); /* pulse width for the remote
rx int pulse */
+ outb(0x00, data_addr); /* this falling edge generates on
normal parport hardware the remote rx interrupt */
cx = nl->trigger;
while (1) {
udelay(PLIP_DELAY_UNIT);
/********************* cut here ****************/
this is the patch for 2.4.1:
/********************* cut here ****************/
--- drivers/net/plip.c.orig Mon Dec 11 21:39:45 2000
+++ drivers/net/plip.c Sun Feb 25 17:19:23 2001
@@ -823,8 +823,10 @@
if ((read_status(dev) & 0xf8) != 0x80)
return HS_TIMEOUT;
- /* Trigger remote rx interrupt. */
- write_data (dev, 0x08);
+ /* Trigger remote rx interrupt using a pulse. */
+ write_data (dev, 0x08); /* this *may* generate an
interrupt on some broken remote parport hardware */
+ udelay(PLIP_TRIGGER_WAIT); /* pulse width for the remote
rx int pulse */
+ write_data (dev, 0x00); /* this falling edge generates
on normal parport hardware the remote rx interrupt */
cx = nl->trigger;
while (1) {
udelay(PLIP_DELAY_UNIT);
/********************* cut here ****************/
Still to be discussed is the wait time for the trigger pulse width and
if it should be configurable as a module parameter or a other tuning
parameter. At the moment I don't need a shorter wait time, but it might
be possible to go down to 10us for the pulse width.
With the standard settings, plip network connection works fine for me on
every starndard PARPORT hardware with a throughput of up to about
2Mbit/sec. I use it even sometimes to run NFS or X over it (docking my
DOS laptop to my computing cluster at home). On my DOS laptop (V30 CPU
with 16MHz) I get a throughput up to 23kB/s using Norton Commander and
the Crynwr PLIP driver.
It would be great to have the plip interface working out of the box
soon.
I sent this patch out to the world already long time ago, but probably I
missed the correct procedure or it was lost, thats why I think it is'nt
in the kernel tree yet.
with best regards,
Johnny
mailto:johannes.lode@gmx.net
------- End of Forwarded Message
-- 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 2b29 : Sun Mar 04 2001 - 14:58:43 EST