Re: [PATCH tty-next v3 1/6] serial: 8250: Adjust the timeout for FIFO mode

[Jiri Slaby]

On 31. 10. 24, 9:49, John Ogness wrote:
> > > > +	/* Allow timeout for each byte written. */
> > > > +	for (i = 0; i < tx_count; i++) {
> > > > +		if (wait_for_lsr(up, UART_LSR_THRE))
> > >
> > > This ensures you sent one character from the FIFO. The FIFO still can contain
> > > plenty of them. Did you want UART_LSR_TEMT?
> >
> >   The difference between THRE and TEMT is the state of the shift register
> > only[2]:
> >
> > "In the FIFO mode, TEMT is set when the transmitter FIFO and shift
> > register are both empty."
>
> If we wait for TEMT, we lose significant advantages of having the FIFO.

But you wait for THRE, so effectively waiting for FIFO to flush. The 
difference is only one byte (TSR), or what am I missing?

> > > But what's the purpose of spinning _here_? The kernel can run and FIFO
> > > too. Without the kernel waiting for the FIFO.
>
> When serial8250_console_fifo_write() exits, the caller just does a
> single wait_for_xmitr() ... with a 10ms timeout. In the FIFO case, for
> <=56k baudrates, it can easily hit the timeout and thus continue before
> the FIFO has been emptied.
> > By waiting on UART_LSR_THRE after filling the FIFO,
> serial8250_console_fifo_write() waits until the hardware has had a
> chance to shift out all the data. Then the final wait_for_xmitr() in the
> caller only waits for the final byte to go out on the line.

For the first loop, that's all right. But why would you want to wait for 
the FIFO to flush at the end of the function? It's not only the last 
byte, it's the last batch (aka 'tx_count'), right?

> Please keep in mind that none of these timeouts should trigger during
> normal operation.
>
> For v4 I am doing some refactoring (as suggested by Andy) so that the
> wait-code looks a bit cleaner.

OK, let's see then :).

thanks,
--
js
suse labs