On Thu, Apr 26, 2012 at 08:59:50AM +0200, Christian Melki wrote:
> From: Christian Melki <christian.melki@xxxxxxxxxxx>
>
> 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).
>
> Signed-off-by: Christian Melki <christian.melki@xxxxxxxxxxx>
> ---
>
> 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 10:31:29.000000000 +0200
> +++ linux-3.3.2/drivers/tty/serial/8250/8250.c 2012-04-26 08:46:29.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;
> + }
> }
This patch doesn't apply at all to my tree, and I can't see why with a
quick glance :(
Can you redo this against the linux-next tree and resend it please?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
