Skip to contentSkip to conversation

8250: Add new UART type SC16C550

PATCH In review Raphael Assenat 2 participants 2 messages Jul 11, 2012 – Jul 12, 2012 TTY layer and serial drivers

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 8250: Add new UART type SC16C550

The NXP SC16C550 has a 16 Byte FIFO and support Automatic Flow Control, enabled by setting bit 5 of MCR (a.k.a. AFE).

This patch adds a new 8250 port type (PORT_SC16C550) to support this chip correcly. Should also work for TI TL16550C/D.

Tested on a custom OMAP board with an SC16C554 (quad uart) attached to the GPMC. We experienced receive overruns when not using AFE.

drivers/tty/serial/8250/8250.c +7 -0
index 6e1958a..ffea4f3 100644
@@ -282,6 +282,13 @@ static const struct serial8250_config uart_config[] = {
 		.fcr		= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
 		.flags		= UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR,
 	},
+	[PORT_SC16C550] = {
+		.name		= "SC16C550",
+		.fifo_size	= 16,
+		.tx_loadsz	= 16,
+		.fcr		= UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+		.flags		= UART_CAP_FIFO | UART_CAP_AFE,
+	},
 };
 
 /* Uart divisor latch read */
include/linux/serial_core.h +2 -1
index 65db992..e472af3 100644
@@ -47,7 +47,8 @@
 #define PORT_U6_16550A	19	/* ST-Ericsson U6xxx internal UART */
 #define PORT_TEGRA	20	/* NVIDIA Tegra internal UART */
 #define PORT_XR17D15X	21	/* Exar XR17D15x UART */
-#define PORT_MAX_8250	21	/* max port ID */
+#define PORT_SC16C550	22	/* NXP SC16C550 and equivalents */
+#define PORT_MAX_8250	22	/* max port ID */
 
 /*
  * ARM specific type numbers.  These are not currently guaranteed
#1 lore raw
Quoted 10 lines · On Wed, 11 Jul 2012 15:54:53 -0400 Raphael Assenat <[email protected]> wrote:

The NXP SC16C550 has a 16 Byte FIFO and support Automatic Flow Control, enabled by setting bit 5 of MCR (a.k.a. AFE).

This patch adds a new 8250 port type (PORT_SC16C550) to support this chip correcly. Should also work for TI TL16550C/D.

Tested on a custom OMAP board with an SC16C554 (quad uart) attached to the GPMC. We experienced receive overruns when not using AFE.

Looks fine and ready to go in as and when patches for the mainline kernel that actually use it go in (ie submit it with the board support once you get that far)

Alan