Re: API to flush rx fifo?

[Peter Hurley <peter@hurleysoftware.com>]

On 06/14/2013 03:12 PM, Grant Edwards wrote:
> 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.]

Yes to both.

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

Either backporting that commit or something similar specifically for
your driver is the only realistic solution. There was nothing suitable
before that.

[ FWIW, I think that commit went in for 3.7 not 3.8 ]