ttymxc uart odd behavior and possible overflow with 3.0.35

[jayakumar2]

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!

[jayakumar2]

Hi,

I did an experiment to remove all other parts of the system like epdc driver, wifi, etc so that the only variable that is relevant is the uart. I wrote a single file test program for the wacom. I have attached the source. I got some unexpected results. In this test, I just wanted to see how long it takes for the serial_mxc driver to notify userspace about uart data. The test procedure is just to run the test, and then hold the pen/stylus continuously on the wacom and then see the first message latency.

a) with wacom set to our normal speed (133 samples/sec)

# WACOM_SR=1 ./wacomtest 

Elapsed 3418ms, Point 0 : 0xa0 4 d a 4a 0, touched point count 0

Elapsed 0ms, Point 1 : 0xa0 4 14 a 4a 0, touched point count 0

...

Elapsed 0ms, Point 507 : 0x80 6 64 a 5b 0, touched point count 466

So it took 3.4s for the first 9 bytes to be received after the uart first byte interrupt was passed to userspace. The number 3418ms is consistent. If I repeat the test 10 times, it is always 3418ms so it looks like that is a timeout that is controlled somewhere. However it is not the options.c_cc[VMIN] parameter as I tried different values there and it is still 3418ms.

If I change the test and touch the panel with the stylus, wait 1s, then lift the stylus, then I get:

Elapsed 984ms, Point 135 : 0xa0 7 1a 9 1f 0, touched point count 101

...

Elapsed 0ms, Point 267 : 0x80 6 4f 8 2a 0, touched point count 208

This is consistent with a separate behavior we observed where the wacom data seems to be buffered at the uart and only passed to userspace after the wacom stops generating data (ie: when the pen is lifted out of range) or the 3418ms timeout occurs.

If I wait 2s before lifting the pen, then I get:

Elapsed 1773ms, Point 0 : 0xa0 7 6b 8 36 0, touched point count 0

...

Elapsed 0ms, Point 237 : 0x80 9 38 7 26 0, touched point count 218

So that latency being correlated with wait time or timeout is consistent.

The key observation is that if I change the wacom's sampling rate to 40 samples/second, then this causes both the latency issue and the overflow issue to go away. Eg:

WACOM_SR=3 ./wacomtest 

Elapsed 6ms, Point 0 : 0xa0 4 19 6 51 0, touched point count 0

Elapsed 6ms, Point 1 : 0xa0 4 1a 6 57 0, touched point count 0

...

Elapsed 7ms, Point 164 : 0x80 4 5d 6 63 0, touched point count 156

In above, we can see that the latency for the same test procedure dropped from 3418ms to 6ms. The other difference is that there is a latency between samples of about 6ms. 

If I change the sample rate to 80 samples/second, then the latency remains good.

WACOM_SR=2 ./wacomtest 

Elapsed 6ms, Point 0 : 0xa0 5 7b 6 12 0, touched point count 0

Elapsed 6ms, Point 1 : 0xa0 5 7b 6 12 0, touched point count 0

...

Elapsed 7ms, Point 155 : 0x80 5 6c 7 55 0, touched point count 133

Since the 6ms latency seems unaffected by the sample rate change between 80 to 40 samples/second, it would look like the latency is due to some interaction between uart driver and application.

At the moment, I'd be happy if I could get the 6ms latency with the normal 133 samples/sec but I can't seem to figure out what uart configuration or parameter controls that latency.

Please let me know if you have any suggestions/ideas.

Thanks!

[igorpadykov]

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!
-----------------------------------------------------------------------------------------------------------------------