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->data_reverse(...)
port->ops->write_control(port, 0x4).
BTW, Microsoft driver controls that my device sends to control register 0x24
before
read - this is the same as two lines above. May be this should be _standart_
operation
by parport_pc?
At ftp.lexmark.com 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" <tomp@trperkins.2y.net>
To: "Max Vorobiev" <pcwizard@telecom.sins.ru>; <linux-parport@torque.net>
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
*buf,
> 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: linux-parport-request@torque.net --
-- 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