Re: omap-serial RX DMA polling?
From: Govindraj <hidden>
Date: 2012-01-23 14:36:57
Also in:
linux-arm-kernel, linux-omap
On Mon, Jan 23, 2012 at 4:17 PM, Paul Walmsley [off-list ref] wrote:
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.
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.
--
Thanks,
Govindraj.R
note: I little busy currently and replies might be delayed.
sorry for any inconvenience.
- Paul 1. At 10 line bits per character (start + byte + stop), each character should take about 2.7 microseconds to transfer (the reciprocal of (3 686 400 line bits per second / 10 line bits per character / 1 000 000 microseconds per second)).
-- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html