[PARPORT] PLIP int fix (fwd)

From: Philip.Blundell@pobox.com
Date: Sun Mar 04 2001 - 14:42:03 EST

  • Next message: schilling@fokus.gmd.de: "Re: [PARPORT] cdrecord 1.10 (write error - loss of streaming) problem"

    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