From: Grant Edwards <grant.b.edwards@gmail.com>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: API to flush rx fifo?
Date: Fri, 14 Jun 2013 12:39:41 -0500 [thread overview]
Message-ID: <20130614173941.GA15623@grante> (raw)
In-Reply-To: <51BB4E64.2000705@hurleysoftware.com>
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.
> 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. What are you supposed to do for kernel
versions that don't have the throttle()/unthrottle() callbacks?
--
Grant
next prev parent reply other threads:[~2013-06-14 17:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 20:03 API to flush rx fifo? Grant Edwards
2013-06-14 14:43 ` Peter Hurley
2013-06-14 15:17 ` Grant Edwards
2013-06-14 15:46 ` Peter Hurley
2013-06-14 16:29 ` Grant Edwards
2013-06-14 17:09 ` Peter Hurley
2013-06-14 17:39 ` Grant Edwards [this message]
2013-06-14 18:04 ` Peter Hurley
2013-06-14 19:12 ` Grant Edwards
2013-06-14 20:53 ` Peter Hurley
2013-06-14 18:41 ` Grant Edwards
2013-06-14 20:19 ` Peter Hurley
2014-02-26 17:14 ` Peter Hurley
2014-02-26 17:51 ` Grant Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130614173941.GA15623@grante \
--to=grant.b.edwards@gmail.com \
--cc=linux-serial@vger.kernel.org \
--cc=peter@hurleysoftware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.