[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Using DMA with ECP ports



1. I haven't been able to repeat this due to lack of hardware
(I built a simple hardware to test it but it doesn't work
yet). But I still think I have found the culprit. The serial
port driver could in some cases restart the parallel port
DMA channel. This can cause the repeated transfers. I will 
send an updated driver in a separate mail. The updates
will also be included in the upcoming devboard_lx release.

2. The parallel port is connected to the DMA through a 
FIFO (64 bytes):

parallel port --> FIFO --> DMA 

In your case I believe the following happens:
1. The parallel port starts to put characters in the FIFO
2. Once the FIFO gets half-full it tells the DMA to get data
3. Before the DMA starts to retrieve the data the FIFO
   gets full (because your device is really fast).
4. After 64 bytes the FIFO is full and no more data can be transferred
5. The DMA starts to read from the FIFO and reads 13 bytes
   (because the descriptor sw_len is 13)
6. The FIFO signals to the parallel port that there is space
   available
7. The parallel port fills up the FIFO again (13 bytes)
8. No more data is transferred because the DMA won't
   accept more data until a new descriptor is added.

The dual transfer is probably caused by the problem described above.

/Mikael


-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
Behalf Of Mike Sloman
Sent: Wednesday, August 21, 2002 9:41 AM
To: dev-etrax
Subject: Using DMA with ECP ports


Hi all,

We are using the etrax 100lx dev board to transfer data from a high
speed modem we our building via ecp through the etrax to a remote
collection point via TCP/IP

We are attempting to get the DMA going with a simple test driver but
have experienced the following problems.

1. While trying to use a single descriptor to transfer to a buffer in
the kernel we get the situation where the data transfers but the
transfer does not stop at the end of the one and only descriptor (with a
d_eol bit set) but restarts some several ms later and sometimes a third
time.  The R_DMA3_FIRST register is still pointing to the first
descriptor even though the documentation says that after a d_eol flagged
descriptor it gets reset to 0.

2. We have now noticed that with a small transfer size (say 13 bytes) we
get two sets of two transfers. The first transfer is 64 bytes long
followed by a 13 byte transfer. A large delay then occurs (ms) and the
dual transfer is repeated.

Using our logic analyser we see the following on the ECP port

64bytes-->125us-->13bytes-->4114us-->64bytes-->125us-->13bytes

looking at the output from the attached code i get this snapshot:
-------------------------------------------------------
General config d40084
Parport 0 config c7010074
Parport 1 config df0000ff
Reg mode: 6 (ecp_fwd(5), ecp_rev(6))
Reg perr == nACKREV: 0 (ecp_rev(0))
Reg nack == nPCLK: 0 (inactive (1), active (0))
Reg busy == PACK: 1 (inactive (0), active (1))
Reg fault == nPREQ: 1 (inactive (1), active (0))
Reg sel: 1 (inactive (0), active (1), xflag(1))
Reg tr_rdy: 0 (busy (0), ready (1))
CH#_FIRST = 1074879272
DMA status = 00
 buff phys = 1074879304 fdesc phys = 1074879272 
point ot first = 1074879272
CH#_FIRST = 1074879272
DMA status = 00
DMA sw_len = 13
time is 0
HZ is 100
Page size = 8192
1sec delay CH#_FIRST = 1074879272
----------------------------------------------------------

In our application data is continually ready for reverse transfer from
the modem thus nPCLK is always active. Is this a problem with the ecp
state machine in the etrax?

Any ideas? (code attached)

Mike.
-- 
Michael Sloman
Engineer, Institute for Telecommunications Research
University of South Australia, Mawson Lakes 5095 , AUSTRALIA
Ph: +618-8302-5168   Fx: +618-8302-3873
Email: mikes@xxxxxxx.au