David Campbell (campbell@torque.net)
Mon, 19 Oct 1998 17:29:38 +0800
Date sent: Mon, 19 Oct 1998 10:25:44 +0200
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
> Daniel E. Ungar wrote:
>
> > I must, right off, confess that the FPGA-implemented port on our x-ray
> > spectrometer is not at all *compliant* with any revision of the IEEE 1284
> > spec'. It merely implements the barest essentials of single-peripheral
> > ECP mode, and if the host does not support that, it cannot in fall back to
>
> I'm in *exactly* the same position :-) And since I also have to
> download the FPGA bitstream in SPP mode, it does not make much
> sense to implement negotiation, as the host knows what the firmware
> can do it downloads.
>
> So there's definitely a need to bypass most of IEEE 1284 ECP, esp.
> negotiation.
*scratch head*
Sounds like you are talking about raw ECP straight from the port.
*snip*
> > What we *do* need is true DMA operation for a data stream of at about
> > 750 KBytes/sec. Any per-byte response to IRQ, or, worse yet, device
> > polling,
Correct device polling can be very efficent, check the example at the end of
this mail message.
> I'm currently using EPP, but the communication overhead is huge
> (baycom_epp).
Huh? You should be able to get more than 600kB/sec down an EPP line
using EPP-16. I current obtain that for the ppa driver and that is including the
drive latency, yields for kenel processing, etc.
Try using insw(base+4, buff, len/2), or for the reckless insl(base, buff, len/4).
EPP-32 is known to fail (badly) on some mainboards due to (I suspect)
problems with PCI-ISA bridges. I have had reports that for the exactly same
IO chipset on two different mainboards, one works in EPP-32 the other fails.
However both mainboards work in EPP-16.
> BTW: It seems that although the ECP protocol could do it, in most
> implementations the host cannot force a direction change
> from backward to forward without possible data loss.
> How did you solve this problem? Just avoid it?
*cough and mutter RTFM* *rummage through chipset datasheets*
Crowbar method (ugly but it works from experience)
=======================================
Place the ECP into FIFO test mode by writing 0xc0 to the ECR
[base+0x402], this stops any further reads or writes to the FIFO. Empty the
FIFO by reading the ECP data register [base+0x400] while watching bit 0 of
the ECR register (FIFO empty bit). When the FIFO is empty, set bit 4 (0x20)
of the parallel port control register (base+2) low, this sets the data direction
to write. Now write 0x60 to the ECR (ECP FIFO mode).
I used a similar method to determine the DMA channel prior to its removal
from the kernel.
> > Can anyone point me to a Linux driver that illustrates the use of DMA?
Quick question, "Why?"
You should be able to do most of this from userland (admittedly this
bypasses parport completely) without the need for DMA. Just remember to
call iopl() with the correct parameter to grant port access. The following is a
quick bit of code which hopefully will explain some tricks to maximise
throughput:
while (!done) {
if (inb(base+0x402) & 0x02) {
insb(base+0x400, buff, 16);
buff+=16;
} else {
nanosleep(2000);
}
}
Assumption:
a) ECP FIFO is 16 bytes long (defined by the IEEE specs so therefore valid)
b) nanosleep() is equivalent to a sleep except the argument is in
nanoseconds, a similar function exists in libc but I am unsure of the
name. The delay may need to be hand tuned for "optimum performance",
too low a value will clobber the system, too high slows the data
throughput.
c) The variable buff is a 'char *', this could be a fixed array providing it is
"emptied" after the insb() call.
d) insb() is defined in "asm/io.h" and is a hand rolled asm loop for transfering
data at high speed, practically as fast as DMA.
Anything else?
David Campbell
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers (documentation needed)
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers (75% complete)
Any assistance to clearing this list most welcome
-- 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 2.0b3 on Wed 30 Dec 1998 - 10:18:37 EST