Re: [PARPORT] ECP, DMA, driver writing

From: Peter Pregler (
Date: Fri Jun 23 2000 - 08:21:20 EDT

  • Next message: Richard Stover: "Re: [PARPORT] ECP, DMA, driver writing"

    On Thu, Jun 22, 2000 at 05:21:01PM -0500, Richard Bonomo wrote:
    > I am struggling with writing a device driver to
    > pull data into the parallel port in ECP mode.
    > I am attempting to read in a continuing stream
    > of data (uncontrolled) and read into into a
    > LARGE RAM buffer.

    This is about what my parport webcam driver does, see cpia_pp.c in the
    2.2.16 kernel. However my LARGE (about 300K IIRC) might not be as LARGE
    as yours. ;)

    > I cannot help but think that this sort of thing
    > is already commonly done, so I thought I'd
    > see if there is already working device code
    > out there that I can get my hands on, and also
    > ask a few questions:

    I did not find any DMA-read code for the parport in Linux. The current
    2.4.X kernel does only do DMA-write. DMA-read should not be that hard
    to add, but someone has to do it and I have not found the time until
    now. And the parport-code in 2.4 is much cleaner than the 2.2 one!

    > 1. Can the parallel port use DMA into high memory
    > nowadays? I have the impression that parallel
    > ports using DMA are restricted to ISA address
    > space on current Intel platforms running Linux.
    > And thus to the lower 16 MB of physical memory.
    > Is this correct?

    If you want your code to be portable do not do it this way. You will
    get all sorts of hardware dependencies. The real big problem you will
    face with DMA this way is to have a contiguous amount of LARGE memory
    allocated in a reliable way. This is _not_ a trivial task.

    > 2. If I reserve upper memory using the "mem=32m"
    > (or whatever size) option at boot, is a simple
    > call to ioremap all that is necessary to make
    > the space available to the kernel? Is there any
    > reason I cannot use a pointer to the physical
    > address when accessing from the kernel?

    There are ways to do such stuff. There is a kernel patch and if you
    really want to do such stuff I can search for the references. But as
    above, this is clumsy and highly non-standard.

    > 3. If DMA direct to high memory is not possible
    > (or is not advisable to avoid tying the bus
    > up for extended periods), is there likely any advantage
    > to DMA to a very small buffer in lower memory
    > and then a copy to a high memory buffer over
    > doing an interrupt-driven programmed i/o directly
    > to a buffer in very high memory?
    > I am running on an Intel platform with a
    > SE440-BX2 motherboard, using Redhat Linux 6.1
    > (linux kernel 2.2.12).

    This is what I chose to do for the webcam driver. I allocate a
    PAGE_SIZE DMA-buffer and copy that in the interrupt-handler to the
    LARGE buffer allocated in more conventional way. Thruput is exept for
    the extrem cases almost independant of the DAM-buffer size. What varies
    is the interrupt congestion. So you just have to make the DMA-buffer
    big enough and PAGE_SIZE is adequate. Of cause you do copy the data
    around once but for modern boards copying data that comes in on
    parport-thruput speed is no problem. If you are restricted to a 386
    that might be a problem. :)


    Even the thought that a ship was waiting to take him back to Earth
    did not wipe out the sense of loss he felt at that moment.

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

    This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 14:43:55 EDT