Hi,
I'm using a 6sl board with linux 3.0.35. I'm using ttymxc1 as a uart to communicate with a wacom touchscreen. I noticed the following issues.
a) /proc info
Firstly, even though ttymxc1 rx is working reasonably, the /proc report shows rx is always 0. Is this a known bug?
# cat /proc/tty/driver/IMX-uart
serinfo:1.0 driver revision:
0: uart:IMX mmio:0x02020000 irq:58 tx:485340 rx:204 RTS|DTR|DSR|CD
1: uart:IMX mmio:0x02024000 irq:59 tx:14 rx:0 DSR|CD
That rx:0 is even though it is clearly continuously receiving data. Eg:
# cat /dev/ttymxc1 | hexdump
0000000 05a0 084a 002c 0048 a000 4f05 2d08 3800
0000010 0000 05a0 0857 0031 0058 a000 6105 3908
0000020 4000 0000 05a0 0868 0041 0060 a000 6b05
0000030 4a08 0000 0000 05a0 0868 0054 0010 a000
0000040 6205 6108 3800 0000 05a0 085b 006d 0058
0000050 a000 5005 7708 5800 0000 05a0 0842 007f
0000060 0020 a000 3205 0309 5000 0000 05a0 0924
0000070 0008 0020 a000 1b05 0c09 2000 0000 05a0
0000080 0917 000e 0000 a000 1205 0d09 6000 0000
0000090 05a0 090b 000d 0048 a000 0405 1109 2800
00000a0 0000 05a0 0900 001e 0060 a000 0005 1e09
b) possible overflow even at 19200 baud
I'm using the following uart settings.
# stty -aF /dev/ttymxc1
speed 19200 baud;stty: /dev/ttymxc1
line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0
ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
The wacom only supports 19200 baud. I have a different board, pxa168 which I use for comparison, also 19200 baud, and I see the data is always complete even with the maximum wacom sampling rate of 133 samples/sec. Whereas with 6sl, with the 133 samples/sec, there appear to be multiple dropped frames. Eg:
cat /dev/ttymxc1 | hexdump
0000000 06a0 072c 000d 0068 a000 3106 1007 2000
0000010 0000 06a0 0738 0015 0040 a000 4206 1d07
0000020 1000 0000 06a0 074c 0028 0000 a000 5706
0000030 3607 0000 0000 06a0 0761 0045 0048 a000
0000040 6c06 5707 5000 0000 06a0 0776 006d 0028
0000050 a000 7d06 7d07 0800 0000 07a0 0804 000c
0000060 0068 a000 0c07 1808 2800 0000 07a0 0813
0000070 0022 0058 a100 1a07 2a08 1801 0000 07a1
0000080 0821 1f33 0038 a100 2707 3c08 403f 0000
0000090 07a1 082f 5342 0070 a100 3607 4c08 5851
Above shows only 160 bytes, only about 16 frames of data whereas pxa168 is delivering much more.
133 samples/sec is well within the 19200 baud rate. (9 bytes per sample, 9 bytes * 133 samples/sec * 8 bits/byte = 9kbps ). If I drop the sampling rate to 80 samples/sec, then I don't get lost frames which is why I suspect the uart of having some overflow issue.
Is there any known overflow issue with the ttymxc1 uart on 3.0.35?
Thanks!
Hi,
Hi Jaya
you are right, there were uart issues and improvements in latest
kernels, so recommended to use latest L4.1.15.
As for L3.0.35 recommended to upgrade to L3.1.101
http://www.nxp.com/webapp/Download?colCode=L3.0.101_4.1.1_SOURCE_BSP&appType=license&location=null&P...
or try to backport attached L3.10.17 uart patch.
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------