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

RE: Using DMA with ECP ports



Greetings Mikael et al,

Thanks for the input. This serial.c fix did not fix my problem but I
have found the solution.

1. I realise now that the initial 64 bytes transferred were from the
refilling of the FIFO after the RESET_DMA command was excecuted. This
did not end up in my buffer and was sent to /dev/null (or the hardware
equivalent :-)  [ I was also relying on the output of the logic analyser
on the parport rather than checking what was actually put into my
buffer]

2. I was using "cat" (implemented in busybox) to read the /proc
interface I had set up and "cat" does not recognise the *eof=1 set at
the end of the proc read function. Thus it returns to the function again
and asks for more data thus forcing the second (or third) dma transfer.
It stops reading from my proc interface when it had got more than 1 page
of data (which as my interface returned variable data length) which was
sometimes 2 or 3 times. I now check to see if the *start value is !=
NULL and just return zero [== EOF for read()] on the next call to the
proc read function.

Thanks again.

Mike.

PS. when is the next devboard_lx release due?? Kernel 2.4.19 I assume??



On Fri, 2002-08-23 at 20:26, Mikael Starvik wrote:
> 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
> 
-- 
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