Hi Jakub, On 17/03/15 14:42, Jakub Kiciński wrote: > On Tue, 17 Mar 2015 13:58:44 +0000, Dave P Martin wrote: >> On Mon, Mar 16, 2015 at 11:15:29PM +0000, Jakub Kicinski wrote: >>> From: Jakub Kicinski <kubakici@xxxxx> [ ... ] >> >> My update still keeps the softirq stuff. I wanted to avoid adding >> status polling inside the interrupt handler's core loop, due to >> concerns about performance overhead: without the polling, the >> writes to DR are fire-and-forget, whereas polling FR each time >> involves a whole round-trip to the UART which may involve significant >> extra time cost and/or IRQ disable latency; however. >> >> Your approach does mitigate some of the cost by only starting to >> poll after count chars have been transmitted, and will typically >> halve the number of IRQs taken -- which could lead to a net benefit. >> It would be good to see some benchmarks to understand how much >> difference it makes to performance. > > I will *try* to come up with some figures but I don't have any > high-speed UARTs so my tests run at 115k tops. Have you tried this? http://fw.hardijzer.nl/?p=138 This drives the RPi PL011 from a higher frequency clock, thus you can achieve much higher baud rates. Haven't tried this myself, but it looks reasonable and not too complicated. You need a matching speed at the other end, of course, AFAIK the FTDI USB chip can do this. Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
