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

From: Dave Strauss (
Date: Thu Aug 23 2001 - 10:07:28 EDT

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

    On Wed, 22 Aug 2001 23:09:07 +0100, Tim Waugh <> wrote:
    > On Wed, Aug 22, 2001 at 04:06:31PM -0400, Dave Strauss wrote:
    > > There are a couple of interesting things about these results. First,
    > > most of the performance gain comes from turning on DMA support on the
    > > host and not from using ECP mode.=20
    > We don't do RLE. That's probably why. If we did RLE then the ECP
    > result would stand a chance of being faster than DMAing in 'printer
    > mode'.
    I don't know of any printers that have implemented ECP RLE mode, nor
    any Windows printers drivers that try to use it. I was just surprised
    that compatibility mode could go so fast.

    > > Second, cutting down on the number
    > > of negotiations into and out of ECP mode (going from config 1 to
    > > config 2) is worth an extra 50 KB/sec or so, at least in this mix of
    > > hosts and printers.
    > Up the LP_BUFFER_SIZE. It's that much slower because we're capping
    > the amount transferred per write to one page. (Duh!) I can't remember
    > exactly why we did that (maybe just arbitrary), but it's obviously
    > hurting here.
    This may or may not help, depending on how big the chunks are that get
    passed into lp. If the application is sending things in small pieces,
    increasing LP_BUFFER_SIZE isn't going to help much.

    > > This second result implies that if we want to get any benefit from ECP
    > > mode in the lp driver we need to cut down the number of negotiations
    > > into and out of ECP mode. The only real way to do this (that I can
    > > see) is to do what I did in config 2 -- put the port into ECP mode
    > > when lp is opened, and leave it there until lp is closed. However
    > > this can cause problems with other drivers which expect the port to be
    > > in kept in compatibility mode. =20
    > Going for this approach can work. If lp declares a 'kick' function at
    > registration time, it can get told to let go of the port.
    Do you mean the "preempt" in the parport device structure? So, lp
    would claim parport on lp_open(), put it into ecp mode, and leave it
    both claimed and in ecp mode until lp_release(). Is that what you
    mean? One problem -- can't the preempt function get called at any
    time? What if it gets called in the middle of a data transfer (or in
    the middle of any other lp entrypoint, for that matter)?

    > > On a semi-related note, the "probe" code in the parport driver
    > > cannot read the IEEE1284 ID from Printer A, even though Windows
    > > boxes have no problem with it. Has any work been done on this code
    > > lately?
    > No, I don't think so. What does deviceid make of it?
    > (<URL:>).

    Same results, which isn't surprising since it uses the same underlying
    code to read the ID data.

    > Tim.
    > */

    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 10:23:48 EDT