Messages in this thread | | | Date | Wed, 24 Nov 1999 12:23:26 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: TTY Flip buffers |
| |
Date: Wed, 24 Nov 1999 14:24:35 +0530 From: Sameer <sameer@multitech.co.in>
A large buffer could solve the problem, but would'nt it be better if the driver could get a fore-warning when the flip buffer was on the verge of getting full? It could then stop the RX interrupts until the "flush_to_ldisc" would empty and flip the flip buffer and inform the driver about the same. I have had instances on a loaded system with all the ports on a mulltiport card doing RX s, the "flush_to_ldisc" will not be scheduled enough to make sufficient free space on the flip buffer for the next RX interrupt.
The driver is supposed to schedule a FLIP operation to take place at the next clock tick. So the problem only comes up if (a) there's enough interrupts going on that the clock tick gets delayed, or (b) the baudrate is faster than (5120 * clock_frequency) (i.e., 512kbps on an i386).
You're never supposed to let the flip buffer get full --- if you do, there's something wrong with your system --- so there's not any need to do any flow control on the thing.
Note also that the flip buffer is only there to improve interrupt latency and efficiency in handling small numbers of characters. For some cards, you may be better off bypassing it altogether. For example, the Rocketport driver has huge on-board FIFO's, is polled on the clock tick, and the driver can read in a hundred character or more at a time. Therefore, there's no point using the flip buffer, and so the Rocketport driver simply calls the line discpline receive_buf() directly.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |