Re: [PARPORT] EPP emulation

From: rjh@world.std.com
Date: Sun Apr 22 2001 - 15:47:10 EDT

  • Next message: Tim Waugh: "Re: [PARPORT] Micro Solutions Backpack CD Rewriter 4E"

    On 21 Apr, Tim Waugh wrote:
    >
    >> There remains the bi-directional issue. ECP has a standard
    >> definition for the process of switching directions. EPP has
    >> traditions, but no official standard.
    >
    > I thought that the 'EPP interrupt' business was for that? I don't
    > have the spec in front of me though.
    >

    My reference says that you "may" use the interrupt for that. Or you can
    use it for anything else you happen to find useful. Hence my
    description of it as a tradition rather than a standard. The ECP rules
    for turnaround are explicit and part of the standard.

    I'm not sure how much to actually worry about interrupts in EPP read
    emulation. There are two key parameters:
     - what is the real peripheral timeout tolerance. 10 usec is the
       specification, but real peripherals often tolerate more. It depends
       on their buffering logic. The EPP does not require failure at 10
       usec. It just permits failure at 10 usec.
     - how fast can Linux service the interrupts. Few can be serviced in
       under 10 usec, many more can be serviced in the real peripheral
       timeout.

       For example, if the peripheral is feeding a typical 16-byte FIFO and
       merely demands an average better than 10 usec per byte, the tolerable
       delay would be about 150 usec before failure. This would make a huge
       difference. Very few interrupt service routines would consume the
       whole 150 usec, and the software emulation will rapidly recover and
       empty the FIFO after the ISR completes.

    My guess is that we just get lucky with most peripherals, and the
    peripherals that demand full EPP performance are just labeled as problem
    peripherals that require DMA.

    R Horn

    -- 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 : Sun Apr 22 2001 - 15:48:17 EDT