Re: API to flush rx fifo?

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2013-06-14, Peter Hurley <peter@hurleysoftware.com> wrote:

>> 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.

Any time you combine high baud rates, large FIFOs, and latency, you
run into that problem.

>>> 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).

Good to know.

Will tty_prepare_flip_string_flags() continue to return a "room"
value?  If so, then I could also switch over to using that instead of
looking at tty->receive_room.  [The advantage being simpler backwards
compatibility.]

The tty_prepare_flip_string_flags() approach also uses a lot less CPU
time than the uart_insert_char() approach.

I'll probably add throttle()/unthrottle() callbacks that set/clear an
internal flag that tells the driver whether or not to read data from
the rx fifo. That should less overhead than polling the tty layer by
calling tty_prepare_flip_string_flags(). But, it doesn't help the
situation for kernels before 3.8.

>> What are you supposed to do for kernel versions that don't have the
>> throttle()/unthrottle() callbacks?
>
> Which versions specifically do you mean?

My serial_core UART drivers support 2.6.25 and newer. The tech support
guys would like support further back, but I've given up trying for
anything older than that. Before our recent change-over to serial_core
drivers (a few months back) I supported 2.6.18 and later. Tech support
would have liked to go back to 2.6.12, which is still in use by some
customers who've tested their systems with some ancient version of RH
and don't want to change it.  One customer just moved from 2.4 to 2.6
about a year ago.

I believe that the throttle/unthrottle callbacks didn't show up until
3.8.  I doubt we even have any customers running 3.8 yet. :)

-- 
Grant Edwards               grant.b.edwards        Yow! I like your SNOOPY
                                  at               POSTER!!
                              gmail.com