On 06/14/2013 01:39 PM, Grant Edwards wrote:
On Fri, Jun 14, 2013 at 01:09:56PM -0400, Peter Hurley wrote:
On 06/14/2013 12:29 PM, Grant Edwards wrote:
Your hardware rx fifo shouldn't have stale data in it because that
should generate an overrun; ie., if the flip buffers cannot accept
data because they're full then the next char pushed when space
becomes available should be a NUL flagged with TTY_OVERRUN.
If flow control is enabled, there should be no rx overruns -- that's
what flow control is for. In the scenario above, flow control is
enabled (and working). In order to allow the UART to handle flow
control, the UART driver must stop reading data from the rx fifo when
the tty layer is "full". The documentation for the serial core API
specifically states that UARTs are allowed to implement flow control
in hardware, and the only way that can be done is to alow the rx fifo
to fill up when the application stops makeing read() calls and the tty
layer fills up.
I think in newer kernels instead of explicitly checking for room in
the tty layer before unloading the rx fifo, the UART is supposed to
rely on the throttle/unthrottle callbacks, but the end result is the
same: when the tty layer gets "full", the UART driver stops reading
data from the rx fifo, and the rx fifo fills up.
AFAIK, only USB serial stops reading the rx fifo on throttle;
All the drivers I maintain do that. It's the only way to get flow
control to work. For UART with large FIFOs (e.g. 1KB) -- espcially
those attached via USB or Ethernet -- flow control driven by code in
serial_core just doesn't work right: you've got to let the UART handle
it.
I had a similar situation with the firewire serial driver (which fakes
serial i/o over the firewire bus @ 250~400Mb/s). The existing throttle
mechanism is too ponderous to shut-off the transmitter before the
receiver overflows the flip buffers.
Currently, that driver buffers rx up on the receiver side but I plan to
change that; right now, the plan is to track the "high watermark" in the
flip buffers and self-throttle when that is too low. Also, I might expose
a way of upping the max flip buffer amount per-port (but probably not
until I add a no-flags-buffer for tty_insert_flip_string_fixed_flag()).
the serial core and other tty drivers continue to empty the rx fifo
-- throttle only shuts off the transmitter on the other end.
Without handling throttle/unthrottle, how are you determining that the
tty layer is "full"? Return code from tty_insert_flip_xxxx()?
I check tty->receive_room.
That will be going away as a means of flow control because it's not
thread-safe (if you backscan this list, my 'lockless n_tty receive path'
patchset only keeps tty->receive_room for the non-flow controlled
line disciplines).
What are you supposed to do for kernel
versions that don't have the throttle()/unthrottle() callbacks?
Which versions specifically do you mean?
Regards,
Peter Hurley
--
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
