The other side does not ignore flow control in the specific case I'm
thinking of (i.e., hardware flow control is enabled and will be used if
needed). However, the on-board buffers on the Z are bigger than the kernel
TTY buffers (8KB for reception against the 4KB TTY buffer), and I want to
make sure that when I call the line discipline's receive function
directly I'm not dropping characters unnecessarily.
How many characters to you read from the Z at a time? Presumably you
want to try to read as many characters as possible, in order to optimize
for processing time, even though this has a negative impact on latency
--- otherwise, why have a 8k hardware receive buffer in the first place.
If you reading that a large number of characters at a time, and getting
periodic interrupts, I'd advice that you skip the flip buffers
altogether and simply call ldisc->receive_buf() directly. As a bonus,
this avoids a memory copy as well. You can use ldisc->receive_room() to
see how much space is available in the 4k tty buffer. (This is what
the Comtrol Rocketport driver does).
The only reason to use the flip buffer is when you want to minimize the
amount of time spent in the interrupt service routine, and when you want
to agregate the overhead cost of line discpline handling over a batch of
characters. If you have a very large hardware buffer to minimize
interrupts, then there probably isn't any need to use the flip buffer
at all, and in fact, the extra overhead argues against it.
Anyhow, what's this flow control signal the tty driver sends to the serial
driver when the buffer starts getting full?? Is this a flag that stays
there until the condition change back to normal, or is it a one-time
signal??
The high-level tty code calls driver->throttle() and
driver->unthrottle() as necessary. See include/linux/tty_driver.h and
include/linux/tty_ldisc.h --- the interfaces are fairly well
documented.
- 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/