Re: [PARPORT] EPP timeout problem

From: Max Vorobiev (
Date: Sun Feb 10 2002 - 13:40:46 EST

  • Next message: Shane Wegner: "[PARPORT] 2.2.18pre parport changes and interrupts"

    Good day.

    Thank yuo very much. Now my problem was solved. Solution is include before
    call "port->ops->epp_read_data(...)"
    two lines:
    port->ops->write_control(port, 0x4).

    BTW, Microsoft driver controls that my device sends to control register 0x24
    read - this is the same as two lines above. May be this should be _standart_
    by parport_pc?
    At I found document "Interfacing Enhanced Parallel Port ver
    1.0". On page 6 it directly tells:
    "Before you can start any EPP cycles by reading and writing to the EPP Data
    and Address Ports, the port must be configured correctly. In the idle state,
    an EPP port should have it's nAddress Strobe, nData Strobe, nWrite and
    nReset lines inactive, high. Some ports require you to set this up before
    starting any EPP Cycle. Therefore our first task is to manually initialise
    these lines using the SPP Registers. Writing XXXX0100 to the control port
    will do this."

    So we are.

    Best regards!

    ----- Original Message -----
    From: "Tom Perkins" <>
    To: "Max Vorobiev" <>; <>
    Sent: Sunday, February 10, 2002 6:18 PM
    Subject: Re: [PARPORT] EPP timeout problem

    > Please state the linux version in use. Also add "verbose_probing=1" to
    > the modprobe options for "parport_pc" and include the log records
    > generated in your report.
    > There is a small code difference between ECP+EPP and EPP modes in
    > 2.4.14. The ECP+EPP code performs a set direction before calling the EPP
    > code.
    > For ex:
    > static size_t parport_pc_ecpepp_read_data (struct parport *port, void
    > size_t length, int flags)
    > {
    > size_t got;
    > frob_econtrol (port, 0xe0, ECR_EPP << 5);
    > ------>
    > parport_pc_data_reverse (port);
    > ------>
    > parport_pc_write_control (port, 0x4);
    > got = parport_pc_epp_read_data (port, buf, length, flags);
    > frob_econtrol (port, 0xe0, ECR_PS2 << 5);
    > return got;
    > }
    > BTW, I have a datasheet for a chipset that claims this is illegal (ie,
    > I'd expect ECP+EPP mode to fail while EPP mode works for this chipset,
    > the opposite of what you're seeing). The problems of trying to support
    > the quirks of ALL chipsets.
    > If you're adventurous try finding the minium set of differences that
    > will make your device work in EPP (only mode) and let us know.
    > Regards,
    > Tom

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

    This archive was generated by hypermail 2b29 : Sun Feb 10 2002 - 13:47:45 EST