On Mon, 23 Jan 2012, Govindraj wrote:

On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley [off-list ref] wrote:

quoted

On Mon, 23 Jan 2012, Govindraj wrote:

quoted

On Mon, Jan 23, 2012 at 6:03 AM, Paul Walmsley [off-list ref] wrote:

quoted

while trying to track down some of the serial-related PM issues in
v3.3-rc1, I noticed that the omap-serial.c driver sets a 1 microsecond
polling timer when DMA is enabled (uart_dma.rx_timer) (!)  This seems
quite broken from both the DMA and PM points of view.

Poll rate is used for doing tty_insert_flip_string for pushing data to
user space to keep faster response to any client device over uart, some
Bt chips expect faster response when data on uart arrives and packet
should be pushed out immediately.

Hmm.  Let's say that the BT transceiver uses the fastest transmission rate
supported by the OMAP UARTs -- 3,686,400 bits per second, according to
Table 17-1 in the 34xx TRM vZR.  So the RX poll timer would go off about
~2.7 times per input character[1].  That seems like overkill...

Yes correct, Looks like the poll rate is to aggressive
it should be calculated based on baud rate provided from user apace
in termios function.

I had a patch to do the same in termios but,
if you have something similar you can post out as I am currently busy with
some other activities and may take more time.

quoted

For minimum receive latency, how about calling tty_insert_flip_string()
from the RX DMA callback, and using a smaller transfer count?  Or even
better, use PIO for the receive path and set the RX FIFO threshold to 1?

No poll timer should be needed in either case.

I remember doing similar excercise with BT + uart on zoom board
but performance numbers where impacted.

I made buffer size as 1 byte and removed polling function and got rx_callback
for every byte completion and pushed same to tty layer.

BT FTP throughput got impacted a lot.

The point is that if you want tty_insert_flip_string() to be called after 
every character is received, there seems little point in using RX DMA.  
It should be less efficient than PIO.  And the current way that it is used 
is pointless from a power management point of view.

In general, RX DMA would seem to be inappropriate for a latency-sensitive 
application, unless the application can somehow communicate how many bytes 
it's expecting so the driver can adjust its DMA transfer size.


- Paul