[PARPORT] DMA ECP reads, partial implementation, need insight.

From: Blaise Gassend (blaise@gassend.com)
Date: Wed May 15 2002 - 18:44:03 EDT

  • Next message: Guido Milanese: "Re: [PARPORT] Imation LS120 install problem"


    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

    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: linux-parport-request@torque.net --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Wed May 15 2002 - 17:45:05 EDT