[Linux-parport] Fwd: OxPCIe952 EPP

Matwey V. Kornilov matwey.kornilov at gmail.com
Sun Feb 26 09:25:10 PST 2017

Hi all,

Two years ago I reported an issue related to EPP mode with OXPCIe952 device:

Recently Mr. Kumar Bhatia kindly provided me with information on
origin of this issue. Full message is forwarded below with his
Shortly, the issue  is the following:

static size_t parport_pc_ecpepp_read_data(struct parport *port, void *buf,
                                          size_t length, int flags)
        size_t got;

        frob_set_mode(port, ECR_EPP);
// The following two lines makes Oxford controller unhappy:
        parport_pc_write_control(port, 0x4);
        got = parport_pc_epp_read_data(port, buf, length, flags);
        frob_set_mode(port, ECR_PS2);

        return got;

It should be pretty straightforward to implement additional
alternative functions to correctly deal with ECP/EPP on Oxford


as well as introduce additional testing into
parport_ECPEPP_supported() to detect Oxford behavior.

Good news that I found my Oxford LPT controller and I even may provide
patch draft on the next week.
Bad news that I don't have any LPT peripheral to test it anymore and
somebody else needs to test it anyway.

p.s. Sorry for duplicate, the maillist doesn't like html mail.

---------- Forwarded message ----------
From: Kumar Bhatia <kumar at softio.com>
Date: 2017-02-26 17:21 GMT+03:00
Subject: Re: [Linux-parport] OxPCIe952 EPP
To: "Matwey V. Kornilov" <matwey.kornilov at gmail.com>

Hello again Matwey. A quick update, we have the OXPCIe952 support
operational in EPP mode (forward & reverse). Please see the details
below. On an aside, we met with the co-founders of Oxford
Semiconductor many years ago when they were a startup. Both founders
were / are very sharp and Dr. Jalil Oraee who designed this chip is a
very bright individual who found flaws in a competitor's datasheet in
seconds of reviewing the timing diagram. He has many patents to his
name and now the CEO of another semiconductor firm. We still stand by
the comment that the Oxford IP is the best in the market.

Summary of the fault:

The Linux driver which LinuxCNC uses is breaking the EPP mode of the
OXPCIe952 and very likely others. Once the ECR register is used to
configure the EPP mode of the controller, DO NOT use the standard
CONTROL port writes as the EPP cycles are generated autonomously by
the controller. OXPCIe952 is strictly an EPP1.7 device.

Moschip 99xx are EPP1.9 devices.

If you remove the writes to the CONTROL port after the EPP
configuration - the OXPCIe952 will work fine in EPP forward & reverse

We have many clients including the US Government using our devices in
EPP mode; also in DOS mode.

If you should update the Linux kernel with our raised fix, please
share the credit of our company name (at least) where due. This will
assist us in future PR. Apparently Jon has been chasing this fault for
over a year now. As you may have noticed, very few players left in the
industry that have this low level knowledge and most companies will
only offer any level of support if there is a logical ROI. It is sad
to say but the truth. Our company has very high volumes of I/O
products so we receive some support but often, we are correcting
silicon faults, correcting datasheet errors & typos. There is another
controller on the market that has a broken EPP engine. We have a fix
for this new device but not yet public on the work around. The silicon
company is using only closed source code and is in denial of the
fault. The EPP support has been removed from their respective
datasheet yet we have the mode working with our external FPGA.

It is important for us to resolve such issues asap and to raise
confidence in our potential customers.

Welcome your feedback. Take care and bye for now.

With best regards,
Matwey V. Kornilov

With best regards,
Matwey V. Kornilov

More information about the Linux-parport mailing list