serial UART async_low_latency does not seem to work. still > 10ms latency!

GoogleGroups
1

Hi all i am writing some software using the OMAP_SERIAL drivers to send and receive data from a c program (TERMIOS).

I am seeing large delays 10ms ticks when sending and receiving data on the UARTS.

In the normal linux driver there is a option called ASYNC_LOW_LATENCY.
When i am setting this flag via IOCTL i was expecting this latency to drop. But it seems ti be ignored by the OMAP_SERIAL driver.

I have tried to set the option both via the following code snippet and via the STTY command line interface.

Any information on this or any way to get the latency down would be much appreciated.

/Thomas

2

speed up to 921600bps or more if your remote uart can work

3

And if you really want the low latency instead of output throw

http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=drivers/tty/serial/omap-serial.c;h=f3aed1f4766742cac97419ff214577b58d19e01b;hb=7e6408234000c6526dae3f55c851adbcaae2d9ef#l1460

Try use lower fifo water marker ,

Try up->port.fifosize = 8;

This might cause data overflow , No guarantee about this ,just try it

4

And another way
try

CONFIG_OMAP_32K_TIMER_HZ=1024

in your kernel CONFIG

5

Hey liyaoshi… I am running both uarts in 3,000,000 bytes per second! It is the problem that i get long delys 10ms or more so it is not related to speed but to latency.
Also it seems the kernel only copies from kernel space to the uart in that same 10ms intervals. so it fills up the send queue for 10ms.

6

So , can you try the 1024HZ for kernel scheduler ?
And , do you have fflush () after you write uart ?

7

This is for UART ? There may even be a kernel boot config option that will work with this hardware as well. Meaning: No need to recompile the kernel to see if it works.

8

Finally CONFIG_HZ will take effects the scheduler

Assuming you use default 32k clock source .from default kernel config and source .

And what I guess if you get delay about 10ms , you might get a delay schedule on 128HZ in default config

So , If you use 1024HZ ,you can get about 1ms latency .

And if the data is very frequency , fifo will not be the problem ,

what I just guess ,

if you only send several bytes in a peak time . fifo might be not enough to generate an interrupt . there is a 64 BYTES fifo in omap uart host controller .

If this case just for bluetooth like

skip fifo setting , just use 1024HZ ,it should be solve