On Sat, Sep 27, 2014 at 01:15:00PM +0200, Janusz Użycki wrote: > It means it is possible but not in Linux today? It depends on your maximum interrupt latency. > I think the problem is not interrupt delay, which is often much below 100us > (we get ~10us delay on DCD). http://archive.arm.linux.org.uk/lurker/message/20130724.145238.44ad37b5.en.html I can believe why this all happens, when you see USB interrupts taking upwards of 3ms to complete: Longest time: 3247506ns Longest irq: 24 Longest handler: usb_hcd_irq+0x0/0x68 This no longer seems to be the case - the maximum interrupt time I'm seeing on recent kernels is: Longest time: 382236ns Longest irq: 62 Longest handler: mv_interrupt+0x0/0x948 My Dove kernel runs permanently with my own maximum interrupt latency tracking enabled. > Isn't the problem rather how to break DMA transmission fast? There are two factors there. The first is being able to tell the DMA engine to stop, the second is the UART hardware FIFO draining. > Hardware flow control not always requires to stop transmission > immediately. No. Hardware flow control is normally implemented at the UART, and CTS is normally implemented to prevent the transmitter starting a new character. Any in-progress character is completed before the transmitter stops, so that there are no errors. At least, this is the behaviour found on the UARTs which I've seen implementing hardware flow control, and it is the only sane way to do it. > Usually delay of some chars is acceptable if remote receiver > implements low/high water mark (overflow trigger lower than RX FIFO size). The receiver you may be communicating with may have a receive FIFO of only 16 characters. It may deassert CTS when it reaches half-full state. That leaves you with only 8 characters to send before it overflows. At 115200 baud, you will have started to send the 9th characters by 700us. However, that isn't the full picture. The full picture is that CTS is normally controlled by software as well, and depends on the availability of buffers to store characters. There's latency at the remote end to deassert CTS in software when the software buffers reach their high watermark, and there's the hope that there is sufficient room in those buffers to take the excess characters that the remote end may continue to send. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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
