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

From: Duncan Haldane (f.duncan.m.haldane@worldnet.att.net)
Date: Fri Dec 27 2002 - 16:46:18 EST

  • Next message: rjh@world.std.com: "Re: [PARPORT] How can cpu use by the parport be limited? (question from new cpia driver maintainer)"


    I've taken over maintenance of the cpia driver for CPiA-based
    webcams (eg. Creative WebCam II, both usb and parport variants).
    While I am mainly interested in usb, I am trying to fix up some
    outstanding issues with parport support.

    I have just implemented the CPiA double-speed variant( see [1] below]
    of nibble mode, so one can now get almost the same (slow) image stream capture
    on non-ECP, non-TRISTATE ports as with software-emulated ECP on
    non-ECP but TRISTATE-capable ports.

    Here's the problem:

    In both software-emulated ECP (TRISTATE non-ECP ports) and
    now this Nibble variant on non-TRISTATE, non-ECP ports, the transfer is
    so cpu intensive that the X-windows becomes blocked (no mouse pointer response
    while an image transfer takes place). I'm getting about 1 byte in 13 usec
    (75K/sec) in the "nibble stream" protocol[1], and the (compressed) image frame
    can be 20K - 350K (max is if it changes completely from the previous frame).

    Breaking up the transmission across the parport into
    chunks of 2048 Bytes helps a lot, by shortening the "dead" period
    between mouse pointer responses.

    There is a user-mode port of the Windows driver (mcam) that doesnt
    cause this blocking of the X-windows response during the image frame
    transmissions, so it is possible.

    Does anyone has any suggestions for some way I can get my kernel-mode
    implementation to behave nicely by not grabbing all available cpu
    resources while processing the nibbles as they dribble across
    the parport interface, (IF that is what is causing the problem, but maybe
    it's some other issue? I have no experience with this, as I am a parport
    novice; what else could be causing it --- some lock?).

    Is this an issue of kernel-non-premptability ?(I'd like to fix it for 2.4.x
    (>2.4.20) kernels, if possible).

    Could putting some delays between transmission of data chunks help?
    (Hmm, maybe I'll try postpoing unscrambling and reassembling the nibbles
    into bytes until the whole chunk of data is available in "nibble stream mode")

    Thanks for any thoughts/advice/suggestions.


    (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?)


    [1] For image streams on non-"BiDiR" ports, CpiA uses a nonstandard "nibble
    stream" protocol that sends the second nibble in response to the host setting
    nAutoFd HI after the first nibble, instead of waiting for nAutoFd to go LO
    again; for reading camera registers it uses a "standard" nibble protocol, but
    doesn't set nDataAvail (nFault LO) after every Byte received, as
    parport_ieee1284_read_nibble() (and, I guess, the ieee1284 standard) requires.

    I got this working by pointing port->ops->nibble_read_data
    to modified private functions derived from parport_ieee1284_read_nibble(),
    using the GPL'd Windows driver and the available CPiA spec sheet as a guide;
    reverse-engineering this by trial-and-error would have been a nightmare!

    E-Mail: Duncan Haldane <f.duncan.m.haldane@worldnet.att.net>
    Date: 27-Dec-2002
    Time: 14:12:10

    This message was sent by XFMail

    -- 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 : Fri Dec 27 2002 - 16:56:46 EST