[#5063] serial uart bfin_5xx.c stops receiving when RX buf wraps (patch included)
Submitted By: Tomasz Motylewski
2009-04-09 04:26:14 Close Date
Medium High Assignee:
Closed Fixed In Release:
Found In Release:
ALL Silicon Revision:
Is this bug repeatable?:
Uboot version or rev.:
Toolchain version or rev.:
08r1.5-14 gcc 4.1.2
App binary format:
Summary: serial uart bfin_5xx.c stops receiving when RX buf wraps (patch included)
The patch blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=commitdiff;h=03869d610feefa6f531c24dc1e4c076d31151f25 fixes bugs [#4455] and [#4436] but a new bug appears:
when receiving small packets of characters sometimes data is not read until next character comes. This happens when the most recent character is exactly at the beginning of the RX buffer. In my case this stops the whole communication - application does not respond, so client does not send anymore till timeout.
What follows is the output of /sys/kernel/debug/blackfin/DMA Controller/DMA8_ ...
CURR_ADDR CURR_X_COUNT CURR_Y_COUNT
0x03f00200 0x0000 0x0000 system start, no chars received
0x03f00001 0x01ff 0x0008 1 character received
0x03f00202 0x01fe 0x0008 next character
0x03f001ff 0x0001 0x0008 next 509 chars
0x03f00200 0x0200 0x0007 next char
0x03f003ff 0x0001 0x0007 next 511 chars
0x03f00400 0x0200 0x0006 next char
0x03f00c00 0x0200 0x0002 next 2048 chars
0x03f00e00 0x0200 0x0001 next 512 chars
0x03f00e01 0x01ff 0x0001 next char
0x03f00fff 0x0001 0x0001 next 510 chars
0x03f01000 0x0000 0x0001 next char SUPRISE, SUPRISE, driver will not receive, expected 0x0200 0x0008
0x03f00001 0x01ff 0x0008 next char, back to normal
This behaviour is documented in BF537_HRM_whole_book_3.0.pdf page 5-15 and others.
To get above data I have enabled debugfs and set 115200 baud. I have sent data from by PC by:
dd if=big-file.txt of=/dev/ttyUSB0 bs=1 count=1 (here comes count in decimal)
I guess DMA8 is just my setup, you will have to find out which is used on your blackfin CPU.
My guess is that cause of [#4455] and [#4436] was not only race condition but also "0x03f01000 0x0000 0x0001" condition which is 100% reproducible when sending characters 1 by 1.
I have fixed and tested it using CURR_X, CURR_Y (see attached patch).
But I would like to suggest considering
if(CURR_Y_COUNT == 0)
return; // ... skip processing, no bytes till now
USE (CURR_ADDR-buffer_start)%buffer_size and delete whole CURR_*_COUNT insanity.
Wolf & Woelfel GmbH
--- Tomasz Motylewski 2009-04-09 06:15:31
I would like to use this opportunity to request shortening poll time in the
driver. Current 20 ms latency is too long. See attached bfin_5xx.c-lowlat.diff
I have tested 2 patches I have attached together.
All was tested in 2008R1.5-RC3 with bfin_5xx.c (2008R1 + patch) and
linux-2.6.x/include/asm-blackfin/mach-bf*/bfin_serial_5xx.h copied from 2008R1
head. I am also attaching the whole patched bfin_5xx.c as is.
Release 0.3 BF537 works the same way.
--- Mike Frysinger 2009-04-09 06:37:01
doesnt the timeout occur only in the error case ? if that's true, you dont want
the timeout function firing when it shouldnt be and so it should stay at 50ms.
--- Tomasz Motylewski 2009-04-09 11:47:29
My understanding is that DMA interrupt only occurs when switching DMA
"lines". You may do test I have describen above checking
After receiving over 4 KB (often single characters) I have:
# cat /proc/interrupts
6: 24524759 BFIN Timer Tick
18: 8 BFIN_UART_RX
19: 291 BFIN_UART_TX
24: 3135 EMAC_RX
That means without "timeout" IRQ happens only every 512 bytes. Good
for throuput but not latency. Even at 115200 baud full load IRQs will only
happen about every 44 ms, while other function polls every 20 ms.
P.S. And please consider removing uart->rx_dma_nrows
--- Tomasz Motylewski 2009-04-09 11:57:26
clarification: in case "0x03f01000 0x0000 0x0001" the characters in
the buffer are NEVER received. "timeout" function simply ignores them
every time it is called. Only when (and if) next character comes, driver copies
the waiting + fresh character.
--- Sonic Zhang 2009-04-23 05:47:31
As Tomasz Motylewski mentioned, this bug is caused by irregular behavior of DMA
register CURR_X_COUNT and CURR_Y_COUNT when an auto restart uart rx DMA run to
last byte in DMA buffer, trigger the interrupt and stay at this possiton. The
status of current x and y is 0:7 instead of 512:8 or 0:8. The driver doesn't
take care of this case when calculating the position.
In addition, the poll interval is set based on normal keyboard input response
time. If you think it is too slow, you need to give a reasonable explanation.
--- Robin Getz 2009-04-23 09:48:02
Can you better define what you mean by "irregular behavior":
- not expected, but described properly in the HRM
- not expected, and not documented in the HRM
From what I can tell - this is the expected behavior per the HRM, and should
not be described as irregular.
--- Sonic Zhang 2009-04-23 23:07:58
Yes, it is described in the DMA part of the HRM. Irregular here means the x and
y status at the last line is different from that of lines in the middle of a 2D
File Name File Type File Size Posted By
bfin_5xx.c-dmafix.diff text/plain 4721 Tomasz Motylewski
bfin_5xx.c text/x-csrc 34897 Tomasz Motylewski
bfin_5xx.c-lowlat.diff text/plain 712 Tomasz Motylewski