8250.c less than 2400 baud fix.

8250.c less than 2400 baud fix.

[Christian Melki]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Hi.

We noticed that we were loosing data at speed less than 2400 baud.
It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr reg.
The input code still fills the buffer with 64 bytes if I remember correctly and thus data is lost.
Our fix was to remove whiping of the fcr content and just add the TRIGGER_1 which we want for latency.
I can't see why this would not work on less than 2400 always, for all uarts...
Otherwise one would have to make sure the filling of the fifo re-checks the current state of available fifo size (urrk).

Best regards,
Christian Melki


[-- Attachment #2: 8250-fix.patch --]
[-- Type: application/octet-stream, Size: 694 bytes --]

diff -urpN linux-3.3.2.orig//drivers/tty/serial/8250/8250.c linux-3.3.2/drivers/tty/serial/8250/8250.c
--- linux-3.3.2.orig//drivers/tty/serial/8250/8250.c	2012-04-25 08:19:35.000000000 +0200
+++ linux-3.3.2/drivers/tty/serial/8250/8250.c	2012-04-25 08:20:35.000000000 +0200
@@ -2299,10 +2299,11 @@ serial8250_do_set_termios(struct uart_po
 		quot++;
 
 	if (up->capabilities & UART_CAP_FIFO && up->port.fifosize > 1) {
-		if (baud < 2400)
-			fcr = UART_FCR_ENABLE_FIFO | UART_FCR_TRIGGER_1;
-		else
-			fcr = uart_config[up->port.type].fcr;
+		fcr = uart_config[up->port.type].fcr;
+		if (baud < 2400) {
+		    fcr &= ~UART_FCR_TRIGGER_MASK;
+		    fcr |= UART_FCR_TRIGGER_1;
+		}
 	}
 
 	/*

Re: 8250.c less than 2400 baud fix.

[Greg KH]

On Wed, Apr 25, 2012 at 02:26:36PM +0200, Christian Melki wrote:
> Hi.
> 
> We noticed that we were loosing data at speed less than 2400 baud.
> It turned out our (TI16750 compatible) uart with 64 byte outgoing fifo was truncated to 16 byte (bit 5 sets fifo len) when modifying the fcr reg.
> The input code still fills the buffer with 64 bytes if I remember correctly and thus data is lost.
> Our fix was to remove whiping of the fcr content and just add the TRIGGER_1 which we want for latency.
> I can't see why this would not work on less than 2400 always, for all uarts...
> Otherwise one would have to make sure the filling of the fifo re-checks the current state of available fifo size (urrk).

Thank you for your fix, but could you take a look at the file,
Documentation/SubmittingPatches and resend it with a Signed-off-by: line
so that I am able to apply the patch?

thanks,

greg k-h