Re: [PARPORT] ECP mode transfers in 2.4.x kernels

From: Dave Strauss (D.Strauss@motorola.com)
Date: Thu Aug 16 2001 - 17:09:54 EDT

  • Next message: Tim Waugh: "Re: [PARPORT] ECP mode transfers in 2.4.x kernels"

    On Thu, 16 Aug 2001 13:42:36 -0400, Dave Strauss <D.Strauss@motorola.com> wrote:
    >
    > On Thu, 16 Aug 2001 18:09:12 +0100, Tim Waugh <twaugh@redhat.com> wrote:
    > >
    > > On Thu, Aug 16, 2001 at 12:52:16PM -0400, Dave Strauss wrote:
    > >
    > > [ ... ]
    > >
    > > > Third problem: the data transfer rate is still very slow. I'm
    > > > expecting upwards [of] 400 Kbytes/sec but [...] getting only about 50
    > > > Kbytes/sec. I'm not [sure] why this is so.
    > >
    > > Philip found this too I think. Is CONFIG_PARPORT_PC_FIFO enabled in
    > > your kernel? Does 'dmesg' say that it's using DMA?
    > >
    > > [ ... ]
    > >
    > > Tim.
    > > */
    > >
    >
    > If the Redhat source RPM really *is* what got shipped,
    > CONFIG_PARPORT_PC_FIFO not set:
    >
    > [ ... ]
    >

    I rebuilt parport_pc with CONFIG_PARPORT_PC_FIFO (I think) and I see
    no difference in performance. Are there any other modules I should be
    replacing? Looks like I might have to haul out a scope or logic
    analyzer to figure out what's going on.

    On a slightly different note, I noticed that this bit of code
    from Philip's original patch is somewhat problematic:

    @@ -269,7 +270,11 @@ static ssize_t lp_write(struct file * fi
              parport_claim_or_block (lp_table[minor].dev);
     
             /* Go to compatibility mode. */
    - parport_negotiate (port, IEEE1284_MODE_COMPAT);
    + if (ret = parport_negotiate (port, lp_table[minor].mode)) {
    + printk(KERN_DEBUG "lp%d: selecting compatibility mode (%d).\n",
    + minor, ret);
    + lp_table[minor].mode = IEEE1284_MODE_COMPAT;
    + }
     

    The problem is that if the peripheral *ever* refuses to go into the
    stored mode it is *always* put into compatibility mode thereafter (at
    least until the lp module unloads). This can be a problem if, for
    example, the peripheral has different operating behavior at different
    times (as mine do) or if the user moves the parallel port cable from
    one peripheral to another (as I do :-). It would be better, I think,
    if the negotiation were attempted at every lp_open().

    The only other information I have at this point is that the garbage
    data problem appears to be hardware-related. I have one printer that
    receives the data with no problem and one printer that receives
    garbled data.

    -- Dave Strauss

    -- 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 : Thu Aug 16 2001 - 17:16:43 EDT