Re: [PARPORT] How can cpu use by the parport be limited? (question from new cpia driver maintainer)

From: Blaise Gassend (
Date: Fri Dec 27 2002 - 20:05:13 EST

  • Next message: Jude DaShiell: "[PARPORT] parallel zip 250 zip drive working with a surprise"


    > (I also need to get ECP-with-DMA working .... need to get a ECP port card for
    > that, though, and only have free PCI slots ...Does 2.4.x have working DMA
    > support for ECP ports?)

    I have a working ECP with DMA patch for 2.4.x kernels. It has been
    working in a stable way for me for about a year now. At the time,
    I uploaded it to the CPiA mailing list. However, for now there is a
    small hack involved which prevents the patch from being put to general
    use. I am pasting my old post below for reference.

    I would have a little time to spend working on this, but I would like
    somebody's opinion on the right way of doing things before I get
    started, and so far the only (not really useful) reaction I have had is
    "there is a bug somewhere in the linux parallel port DMA support".

    Blaise Gassend

    ---------- Snip ------------


    I have written an ECP DMA read function for the parrallel port that I
    have been using with my CPiA webcam for a few months now. So far it will
    only work with the webcam because a little hack that I had to do, and I
    am looking insight on how should get around the hack. My only experience
    with ECP is with my webcam, so I might have a biased view of how things

    The main difficulty I am having comes from the buffer. I can tell the
    DMA how many bytes I want to read, but the ECP buffer will read more
    data than that. This is fine for CPiA (and I expect it is okay in most
    cases) as we want to read all the data the device has to send. I simply
    leave data sitting in the buffer, ready for the next read from the CPiA
    driver. The problem is that if I want to leave the data in the buffer
    before reads, I can't return the parallel port to PS/2 mode between
    reads. However, I have to return the parallel port to PS/2 mode before
    the next ECP mode negotiation takes place (the parport_negotiate
    function in ieee1284.c).

    This is where the hack is. Since there doesn't seem to be any way for
    parport_pc to intercept the call to parport_negotiate, I have hacked the
    CPiA driver so that it restores PS/2 mode just before doing ECP mode
    negotiations. This is fine for me, and has been working in a stable way
    since december.

    But now I would like to contribute my code to the community, and so I
    have to find a cleaner way of doing things. This is where I need some

    1) For people who have knowledge of protocols for other parallel
    devices, will reading data into the buffer prematurely cause problems?

    2) How should I get around the parport_negotiate problem? Should I add
    it to the functions that can be overloaded by hardware specific drivers,
    or should the CPiA driver in fact be calling some other hardware
    specific function that I could have intercepted in the parport_pc driver
    to get back into PS/2 mode before ECP mode negocitaion.

    Thanks for your insight,
    Blaise Gassend

    PS If anybody wants the preliminary code, just ask.

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

    This archive was generated by hypermail 2b29 : Sat Dec 28 2002 - 08:20:11 EST