On Tue, 17 Mar 2015 14:49:18 +0000, Andre Przywara wrote: > 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. Thanks, I will give it a go. I do have FTDI chip for RS-485 about which I did not think (and a hacked-up RS-485 support in PL011 driver). Also not connecting anything on the other side could work as we are talking only about TX, no? -- 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
