atmel_serial: Atmel RS485 support v2

Hi all,

this is the new version of the patch to add RS485 support to the atmel_serial driver. It's been changed according to Ryan Mallon's comments.

This new patch has been tested again (with and without DMA) by Sebastian Heutling (CC:-ed).

Many thanks to all,

Claudio

atmel_serial: Atmel RS485 support

Signed-off-by Claudio Scordino <[email protected]>

Signed-off-by Michael Trimarchi <[email protected]>

Signed-off-by Rick Bronson <[email protected]>

Signed-off-by Sebastian Heutling <[email protected]>

---
 arch/arm/include/asm/ioctls.h           |    2 +
 arch/arm/mach-at91/include/mach/board.h |    2 +
 drivers/serial/atmel_serial.c           |  244 ++++++++++++++++++++++++++-----
 3 files changed, 212 insertions(+), 36 deletions(-)

arch/arm/include/asm/ioctls.h +2 -0

index a91d8a1..82f2177 100644
@@ -70,6 +70,8 @@
 #define TIOCGICOUNT	0x545D	/* read serial port inline interrupt counts */
 #define FIOQSIZE	0x545E
 
+#define TIOCSRS485	0x5461
+
 /* Used for packet mode */
 #define TIOCPKT_DATA		 0
 #define TIOCPKT_FLUSHREAD	 1

arch/arm/mach-at91/include/mach/board.h +1 -0

index ceaec6c..fd8a385 100644
@@ -39,6 +39,7 @@
 #include <linux/usb/atmel_usba_udc.h>
 #include <linux/atmel-mci.h>
 #include <sound/atmel-ac97c.h>
+#include <linux/serial.h>
 
  /* USB Device */
 struct at91_udc_data {

arch/arm/mach-at91/include/mach/board.h +0 -0

 extern void __init at91_add_device_serial(void);
 

drivers/serial/atmel_serial.c +5 -0

index 2c9bf9b..826a885 100644
@@ -38,6 +38,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/atmel_pdc.h>
 #include <linux/atmel_serial.h>
+#include <linux/uaccess.h>
 
 #include <asm/io.h>
 

@@ -59,6 +60,9 @@
 
 #include <linux/serial_core.h>
 
+static void atmel_start_rx(struct uart_port *port);
+static void atmel_stop_rx(struct uart_port *port);
+
 #ifdef CONFIG_SERIAL_ATMEL_TTYAT
 
 /* Use device name ttyAT, major 204 and minor 154-169.  This is necessary if we

@@ -93,6 +97,7 @@
 #define UART_GET_BRGR(port)	__raw_readl((port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_BRGR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
+#define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
 
  /* PDC registers */
 #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)

drivers/serial/atmel_serial.c +16 -0

 static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];

@@ -187,6 +196,81 @@ static bool atmel_use_dma_tx(struct uart_port *port)
 }
 #endif
 
+/* Enable or disable the rs485 support */
+void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	unsigned long flags;
+	unsigned int mode;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	mode = UART_GET_MR(port);
+
+	/* Resetting serial mode to RS232 (0x0) */
+	mode &= ~ATMEL_US_USMODE;
+
+	atmel_port->rs485 = *rs485conf;
+

drivers/serial/atmel_serial.c +18 -0

+	struct platform_device *pdev = to_platform_device(dev);
+	struct uart_port *port = platform_get_drvdata(pdev);
+	unsigned int current_mode;
+
+	current_mode = UART_GET_MR(port) & ATMEL_US_USMODE;
+	return snprintf(buf, PAGE_SIZE, "%u\n", current_mode);
+}
+
+static ssize_t set_rs485(struct device *dev, struct device_attribute *attr, \
+			  const char *buf, size_t len)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct uart_port *port = platform_get_drvdata(pdev);
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct serial_rs485 rs485conf = atmel_port->rs485;
+	unsigned int value;
+
+	if (!buf)

drivers/serial/atmel_serial.c +10 -0

+	}
+
+	atmel_config_rs485(port, &rs485conf);
+
+	return strnlen(buf, PAGE_SIZE);
+}
+
+static DEVICE_ATTR(rs485, 0644, show_rs485, set_rs485);
+
 /*
  * Return TIOCSER_TEMT when transmitter FIFO and Shift register is empty.
  */

@@ -202,6 +286,7 @@ static void atmel_set_mctrl(struct uart_port *port, u_int mctrl)
 {
 	unsigned int control = 0;
 	unsigned int mode;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
 #ifdef CONFIG_ARCH_AT91RM9200
 	if (cpu_is_at91rm9200()) {

drivers/serial/atmel_serial.c +73 -25

+		UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_before_send);
+		mode |= ATMEL_US_USMODE_RS485;
+	} else {
+		dev_dbg(port->dev, "Keeping UART to RS232\n");
+	}
 	UART_PUT_MR(port, mode);
 }
 

@@ -268,12 +364,17 @@ static u_int atmel_get_mctrl(struct uart_port *port)
  */
 static void atmel_stop_tx(struct uart_port *port)
 {
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
 	if (atmel_use_dma_tx(port)) {
 		/* disable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
-		UART_PUT_IDR(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
-	} else
-		UART_PUT_IDR(port, ATMEL_US_TXRDY);
+	}
+	/* Disable interrupts */
+	UART_PUT_IDR(port, atmel_port->tx_done_mask);
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+		atmel_start_rx(port);
 }
 
 /*

@@ -281,17 +382,39 @@ static void atmel_stop_tx(struct uart_port *port)
  */
 static void atmel_start_tx(struct uart_port *port)
 {
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
 	if (atmel_use_dma_tx(port)) {
 		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
 			/* The transmitter is already running.  Yes, we
 			   really need this.*/
 			return;
 
-		UART_PUT_IER(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+			atmel_stop_rx(port);
+
 		/* re-enable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTEN);
-	} else
-		UART_PUT_IER(port, ATMEL_US_TXRDY);
+	}
+	/* Enable interrupts */
+	UART_PUT_IER(port, atmel_port->tx_done_mask);
+}
+
+/*
+ * start receiving - port is in process of being opened.
+ */
+static void atmel_start_rx(struct uart_port *port)
+{
+	UART_PUT_CR(port, ATMEL_US_RSTSTA);  /* reset status and receiver */
+
+	if (atmel_use_dma_rx(port)) {
+		/* enable PDC controller */
+		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT | \
+			port->read_status_mask);
+		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
+	} else {
+		UART_PUT_IER(port, ATMEL_US_RXRDY);
+	}
 }
 
 /*

@@ -302,9 +425,11 @@ static void atmel_stop_rx(struct uart_port *port)
 	if (atmel_use_dma_rx(port)) {
 		/* disable PDC receive */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
-		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
-	} else
+		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT | \
+			port->read_status_mask);
+	} else {
 		UART_PUT_IDR(port, ATMEL_US_RXRDY);
+	}
 }
 
 /*

@@ -428,8 +553,9 @@ static void atmel_rx_chars(struct uart_port *port)
 static void atmel_tx_chars(struct uart_port *port)
 {
 	struct circ_buf *xmit = &port->state->xmit;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (port->x_char && UART_GET_CSR(port) & ATMEL_US_TXRDY) {
+	if (port->x_char && UART_GET_CSR(port) & atmel_port->tx_done_mask) {
 		UART_PUT_CHAR(port, port->x_char);
 		port->icount.tx++;
 		port->x_char = 0;

@@ -437,7 +563,7 @@ static void atmel_tx_chars(struct uart_port *port)
 	if (uart_circ_empty(xmit) || uart_tx_stopped(port))
 		return;
 
-	while (UART_GET_CSR(port) & ATMEL_US_TXRDY) {
+	while (UART_GET_CSR(port) & atmel_port->tx_done_mask) {
 		UART_PUT_CHAR(port, xmit->buf[xmit->tail]);
 		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
 		port->icount.tx++;

@@ -449,7 +575,8 @@ static void atmel_tx_chars(struct uart_port *port)
 		uart_write_wakeup(port);
 
 	if (!uart_circ_empty(xmit))
-		UART_PUT_IER(port, ATMEL_US_TXRDY);
+		/* Enable interrupts */
+		UART_PUT_IER(port, atmel_port->tx_done_mask);
 }
 
 /*

@@ -501,18 +628,10 @@ atmel_handle_transmit(struct uart_port *port, unsigned int pending)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
-		/* PDC transmit */
-		if (pending & (ATMEL_US_ENDTX | ATMEL_US_TXBUFE)) {
-			UART_PUT_IDR(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
-			tasklet_schedule(&atmel_port->tasklet);
-		}
-	} else {
-		/* Interrupt transmit */
-		if (pending & ATMEL_US_TXRDY) {
-			UART_PUT_IDR(port, ATMEL_US_TXRDY);
-			tasklet_schedule(&atmel_port->tasklet);
-		}
+	if (pending & atmel_port->tx_done_mask) {
+		/* Either PDC or interrupt transmission */
+		UART_PUT_IDR(port, atmel_port->tx_done_mask);
+		tasklet_schedule(&atmel_port->tasklet);
 	}
 }
 

@@ -590,9 +709,15 @@ static void atmel_tx_dma(struct uart_port *port)
 
 		UART_PUT_TPR(port, pdc->dma_addr + xmit->tail);
 		UART_PUT_TCR(port, count);
-		/* re-enable PDC transmit and interrupts */
+		/* re-enable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTEN);
-		UART_PUT_IER(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
+		/* Enable interrupts */
+		UART_PUT_IER(port, atmel_port->tx_done_mask);
+	} else {
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+			/* DMA done, stop TX, start RX for RS485 */
+			atmel_start_rx(port);
+		}
 	}
 
 	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)

@@ -1017,6 +1142,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 {
 	unsigned long flags;
 	unsigned int mode, imr, quot, baud;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
 	/* Get current mode register */
 	mode = UART_GET_MR(port) & ~(ATMEL_US_USCLKS | ATMEL_US_CHRL

@@ -1115,6 +1241,17 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 	/* disable receiver and transmitter */
 	UART_PUT_CR(port, ATMEL_US_TXDIS | ATMEL_US_RXDIS);
 
+	/* Resetting serial mode to RS232 (0x0) */
+	mode &= ~ATMEL_US_USMODE;
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Keeping UART to RS485\n");
+		UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_before_send);
+		mode |= ATMEL_US_USMODE_RS485;
+	} else {
+		dev_dbg(port->dev, "Keeping UART to RS232\n");
+	}
+
 	/* set the parity, stop bits and data size */
 	UART_PUT_MR(port, mode);
 

@@ -1231,6 +1368,30 @@ static void atmel_poll_put_char(struct uart_port *port, unsigned char ch)
 }
 #endif
 
+static int
+atmel_ioctl(struct uart_port *port, unsigned int cmd, unsigned long arg)

drivers/serial/atmel_serial.c +32 -11

+
+		atmel_config_rs485(port, &rs485conf);
+		break;
+
+	default:
+		return -ENOIOCTLCMD;
+	}
+	return 0;
+}
+
+
+
 static struct uart_ops atmel_pops = {
 	.tx_empty	= atmel_tx_empty,
 	.set_mctrl	= atmel_set_mctrl,

@@ -1250,6 +1411,7 @@ static struct uart_ops atmel_pops = {
 	.config_port	= atmel_config_port,
 	.verify_port	= atmel_verify_port,
 	.pm		= atmel_serial_pm,
+	.ioctl		= atmel_ioctl,
 #ifdef CONFIG_CONSOLE_POLL
 	.poll_get_char	= atmel_poll_get_char,
 	.poll_put_char	= atmel_poll_put_char,

@@ -1265,13 +1427,12 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
 	struct uart_port *port = &atmel_port->uart;
 	struct atmel_uart_data *data = pdev->dev.platform_data;
 
-	port->iotype	= UPIO_MEM;
-	port->flags	= UPF_BOOT_AUTOCONF;
-	port->ops	= &atmel_pops;
-	port->fifosize	= 1;
-	port->line	= pdev->id;
-	port->dev	= &pdev->dev;
-
+	port->iotype		= UPIO_MEM;
+	port->flags		= UPF_BOOT_AUTOCONF;
+	port->ops		= &atmel_pops;
+	port->fifosize		= 1;
+	port->line		= pdev->id;
+	port->dev		= &pdev->dev;
 	port->mapbase	= pdev->resource[0].start;
 	port->irq	= pdev->resource[1].start;
 

@@ -1299,8 +1460,16 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
 
 	atmel_port->use_dma_rx = data->use_dma_rx;
 	atmel_port->use_dma_tx = data->use_dma_tx;
-	if (atmel_use_dma_tx(port))
+	atmel_port->rs485	= data->rs485;
+	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
+	else if (atmel_use_dma_tx(port)) {
 		port->fifosize = PDC_BUFFER_SIZE;
+		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
+	} else {
+		atmel_port->tx_done_mask = ATMEL_US_TXRDY;
+	}
 }
 
 /*

@@ -1334,6 +1503,7 @@ static void atmel_console_putchar(struct uart_port *port, int ch)
 static void atmel_console_write(struct console *co, const char *s, u_int count)
 {
 	struct uart_port *port = &atmel_ports[co->index].uart;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	unsigned int status, imr;
 	unsigned int pdc_tx;
 

@@ -1341,7 +1511,7 @@ static void atmel_console_write(struct console *co, const char *s, u_int count)
 	 * First, save IMR and then disable interrupts
 	 */
 	imr = UART_GET_IMR(port);
-	UART_PUT_IDR(port, ATMEL_US_RXRDY | ATMEL_US_TXRDY);
+	UART_PUT_IDR(port, ATMEL_US_RXRDY | atmel_port->tx_done_mask);
 
 	/* Store PDC transmit status and disable it */
 	pdc_tx = UART_GET_PTSR(port) & ATMEL_PDC_TXTEN;

@@ -1355,7 +1525,7 @@ static void atmel_console_write(struct console *co, const char *s, u_int count)
 	 */
 	do {
 		status = UART_GET_CSR(port);
-	} while (!(status & ATMEL_US_TXRDY));
+	} while (!(status & atmel_port->tx_done_mask));
 
 	/* Restore PDC transmit status */
 	if (pdc_tx)

@@ -1587,7 +1757,7 @@ static int __devinit atmel_serial_probe(struct platform_device *pdev)
 	device_init_wakeup(&pdev->dev, 1);
 	platform_set_drvdata(pdev, port);
 
-	return 0;
+	return device_create_file(&(pdev->dev), &dev_attr_rs485);
 
 err_add_port:
 	kfree(port->rx_ring.buf);

Quoted 8 lines · Claudio Scordino

Hi all,

this is the new version of the patch to add RS485 support to the atmel_serial driver. It's been changed according to Ryan Mallon's comments.

This new patch has been tested again (with and without DMA) by Sebastian Heutling (CC:-ed).

A few more, mostly nitpicky, comments below.

Ryan Mallon ha scritto:

Quoted 9 lines

Quoted 8 lines · Claudio Scordino

Hi all,

this is the new version of the patch to add RS485 support to the atmel_serial driver. It's been changed according to Ryan Mallon's comments.

This new patch has been tested again (with and without DMA) by Sebastian Heutling (CC:-ed).

Quoted 1 line

A few more, mostly nitpicky, comments below.

Hi Ryan,

many thanks for your feedback.

Please find attached a new version of the patch, modified according to your comments.

Regards,

Claudio

atmel_serial: Atmel RS485 support

Signed-off-by Claudio Scordino <[email protected]>

Signed-off-by Michael Trimarchi <[email protected]>

Signed-off-by Rick Bronson <[email protected]>

Signed-off-by Sebastian Heutling <[email protected]>

---
 arch/arm/include/asm/ioctls.h           |    2 +
 arch/arm/mach-at91/include/mach/board.h |    8 +-
 drivers/serial/atmel_serial.c           |  241 ++++++++++++++++++++++++++-----
 3 files changed, 212 insertions(+), 39 deletions(-)

arch/arm/include/asm/ioctls.h +2 -0

index a91d8a1..82f2177 100644
@@ -70,6 +70,8 @@
 #define TIOCGICOUNT	0x545D	/* read serial port inline interrupt counts */
 #define FIOQSIZE	0x545E
 
+#define TIOCSRS485	0x5461
+
 /* Used for packet mode */
 #define TIOCPKT_DATA		 0
 #define TIOCPKT_FLUSHREAD	 1

arch/arm/mach-at91/include/mach/board.h +5 -3

index ceaec6c..df2ed84 100644
@@ -39,6 +39,7 @@
 #include <linux/usb/atmel_usba_udc.h>
 #include <linux/atmel-mci.h>
 #include <sound/atmel-ac97c.h>
+#include <linux/serial.h>
 
  /* USB Device */
 struct at91_udc_data {

@@ -143,9 +144,10 @@ extern struct platform_device *atmel_default_console_device;
 extern void __init __deprecated at91_init_serial(struct at91_uart_config *config);
 
 struct atmel_uart_data {
-	short		use_dma_tx;	/* use transmit DMA? */
-	short		use_dma_rx;	/* use receive DMA? */
-	void __iomem	*regs;		/* virtual base address, if any */
+	short			use_dma_tx;	/* use transmit DMA? */
+	short			use_dma_rx;	/* use receive DMA? */
+	void __iomem		*regs;		/* virt. base address, if any */
+	struct serial_rs485	rs485;		/* rs485 settings */
 };
 extern void __init at91_add_device_serial(void);
 

drivers/serial/atmel_serial.c +205 -36

index 2c9bf9b..039cd65 100644
@@ -38,6 +38,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/atmel_pdc.h>
 #include <linux/atmel_serial.h>
+#include <linux/uaccess.h>
 
 #include <asm/io.h>
 

@@ -59,6 +60,9 @@
 
 #include <linux/serial_core.h>
 
+static void atmel_start_rx(struct uart_port *port);
+static void atmel_stop_rx(struct uart_port *port);
+
 #ifdef CONFIG_SERIAL_ATMEL_TTYAT
 
 /* Use device name ttyAT, major 204 and minor 154-169.  This is necessary if we

@@ -93,6 +97,7 @@
 #define UART_GET_BRGR(port)	__raw_readl((port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_BRGR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_BRGR)
 #define UART_PUT_RTOR(port,v)	__raw_writel(v, (port)->membase + ATMEL_US_RTOR)
+#define UART_PUT_TTGR(port, v)	__raw_writel(v, (port)->membase + ATMEL_US_TTGR)
 
  /* PDC registers */
 #define UART_PUT_PTCR(port,v)	__raw_writel(v, (port)->membase + ATMEL_PDC_PTCR)

@@ -147,6 +152,9 @@ struct atmel_uart_port {
 	unsigned int		irq_status_prev;
 
 	struct circ_buf		rx_ring;
+
+	struct serial_rs485	rs485;		/* rs485 settings */
+	unsigned int		tx_done_mask;
 };
 
 static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];

@@ -187,6 +195,81 @@ static bool atmel_use_dma_tx(struct uart_port *port)
 }
 #endif
 
+/* Enable or disable the rs485 support */
+void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
+{
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	unsigned long flags;
+	unsigned int mode;
+
+	spin_lock_irqsave(&port->lock, flags);
+
+	mode = UART_GET_MR(port);
+
+	/* Resetting serial mode to RS232 (0x0) */
+	mode &= ~ATMEL_US_USMODE;
+
+	atmel_port->rs485 = *rs485conf;
+
+	if (rs485conf->flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
+		UART_PUT_TTGR(port, rs485conf->delay_rts_before_send);
+		mode |= ATMEL_US_USMODE_RS485;
+	} else {
+		dev_dbg(port->dev, "Setting UART to RS232\n");
+		if (atmel_use_dma_tx(port))
+			atmel_port->tx_done_mask = ATMEL_US_ENDTX |
+				ATMEL_US_TXBUFE;
+		else
+			atmel_port->tx_done_mask = ATMEL_US_TXRDY;
+	}
+	UART_PUT_MR(port, mode);
+
+	spin_unlock_irqrestore(&port->lock, flags);
+}
+
+
+static ssize_t show_rs485(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct uart_port *port = platform_get_drvdata(pdev);
+	unsigned int current_mode;
+
+	current_mode = UART_GET_MR(port) & ATMEL_US_USMODE;
+	return snprintf(buf, PAGE_SIZE, "%u\n", current_mode);
+}
+
+static ssize_t set_rs485(struct device *dev, struct device_attribute *attr,
+			  const char *buf, size_t len)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct uart_port *port = platform_get_drvdata(pdev);
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+	struct serial_rs485 rs485conf = atmel_port->rs485;
+	unsigned int value;
+
+	if (!buf)
+		return -EINVAL;
+
+	value = !!(simple_strtoul(buf, NULL, 0));
+
+	if (value) {
+		rs485conf.flags |= SER_RS485_ENABLED;
+		/* 0x4 is the normal reset value. */
+		rs485conf.delay_rts_before_send = 0x00000004;
+	} else {
+		rs485conf.flags &= ~SER_RS485_ENABLED;
+	}
+
+	atmel_config_rs485(port, &rs485conf);
+
+	return strnlen(buf, PAGE_SIZE);
+}
+
+static DEVICE_ATTR(rs485, 0644, show_rs485, set_rs485);
+
 /*
  * Return TIOCSER_TEMT when transmitter FIFO and Shift register is empty.
  */

@@ -202,6 +285,7 @@ static void atmel_set_mctrl(struct uart_port *port, u_int mctrl)
 {
 	unsigned int control = 0;
 	unsigned int mode;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
 #ifdef CONFIG_ARCH_AT91RM9200
 	if (cpu_is_at91rm9200()) {

@@ -236,6 +320,17 @@ static void atmel_set_mctrl(struct uart_port *port, u_int mctrl)
 		mode |= ATMEL_US_CHMODE_LOC_LOOP;
 	else
 		mode |= ATMEL_US_CHMODE_NORMAL;
+
+	/* Resetting serial mode to RS232 (0x0) */
+	mode &= ~ATMEL_US_USMODE;
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_before_send);
+		mode |= ATMEL_US_USMODE_RS485;
+	} else {
+		dev_dbg(port->dev, "Setting UART to RS232\n");
+	}
 	UART_PUT_MR(port, mode);
 }
 

@@ -268,12 +363,17 @@ static u_int atmel_get_mctrl(struct uart_port *port)
  */
 static void atmel_stop_tx(struct uart_port *port)
 {
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
 	if (atmel_use_dma_tx(port)) {
 		/* disable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTDIS);
-		UART_PUT_IDR(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
-	} else
-		UART_PUT_IDR(port, ATMEL_US_TXRDY);
+	}
+	/* Disable interrupts */
+	UART_PUT_IDR(port, atmel_port->tx_done_mask);
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+		atmel_start_rx(port);
 }
 
 /*

@@ -281,17 +381,39 @@ static void atmel_stop_tx(struct uart_port *port)
  */
 static void atmel_start_tx(struct uart_port *port)
 {
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
+
 	if (atmel_use_dma_tx(port)) {
 		if (UART_GET_PTSR(port) & ATMEL_PDC_TXTEN)
 			/* The transmitter is already running.  Yes, we
 			   really need this.*/
 			return;
 
-		UART_PUT_IER(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+			atmel_stop_rx(port);
+
 		/* re-enable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTEN);
-	} else
-		UART_PUT_IER(port, ATMEL_US_TXRDY);
+	}
+	/* Enable interrupts */
+	UART_PUT_IER(port, atmel_port->tx_done_mask);
+}
+
+/*
+ * start receiving - port is in process of being opened.
+ */
+static void atmel_start_rx(struct uart_port *port)
+{
+	UART_PUT_CR(port, ATMEL_US_RSTSTA);  /* reset status and receiver */
+
+	if (atmel_use_dma_rx(port)) {
+		/* enable PDC controller */
+		UART_PUT_IER(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
+			port->read_status_mask);
+		UART_PUT_PTCR(port, ATMEL_PDC_RXTEN);
+	} else {
+		UART_PUT_IER(port, ATMEL_US_RXRDY);
+	}
 }
 
 /*

@@ -302,9 +424,11 @@ static void atmel_stop_rx(struct uart_port *port)
 	if (atmel_use_dma_rx(port)) {
 		/* disable PDC receive */
 		UART_PUT_PTCR(port, ATMEL_PDC_RXTDIS);
-		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT);
-	} else
+		UART_PUT_IDR(port, ATMEL_US_ENDRX | ATMEL_US_TIMEOUT |
+			port->read_status_mask);
+	} else {
 		UART_PUT_IDR(port, ATMEL_US_RXRDY);
+	}
 }
 
 /*

@@ -428,8 +552,9 @@ static void atmel_rx_chars(struct uart_port *port)
 static void atmel_tx_chars(struct uart_port *port)
 {
 	struct circ_buf *xmit = &port->state->xmit;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (port->x_char && UART_GET_CSR(port) & ATMEL_US_TXRDY) {
+	if (port->x_char && UART_GET_CSR(port) & atmel_port->tx_done_mask) {
 		UART_PUT_CHAR(port, port->x_char);
 		port->icount.tx++;
 		port->x_char = 0;

@@ -437,7 +562,7 @@ static void atmel_tx_chars(struct uart_port *port)
 	if (uart_circ_empty(xmit) || uart_tx_stopped(port))
 		return;
 
-	while (UART_GET_CSR(port) & ATMEL_US_TXRDY) {
+	while (UART_GET_CSR(port) & atmel_port->tx_done_mask) {
 		UART_PUT_CHAR(port, xmit->buf[xmit->tail]);
 		xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
 		port->icount.tx++;

@@ -449,7 +574,8 @@ static void atmel_tx_chars(struct uart_port *port)
 		uart_write_wakeup(port);
 
 	if (!uart_circ_empty(xmit))
-		UART_PUT_IER(port, ATMEL_US_TXRDY);
+		/* Enable interrupts */
+		UART_PUT_IER(port, atmel_port->tx_done_mask);
 }
 
 /*

@@ -501,18 +627,10 @@ atmel_handle_transmit(struct uart_port *port, unsigned int pending)
 {
 	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-	if (atmel_use_dma_tx(port)) {
-		/* PDC transmit */
-		if (pending & (ATMEL_US_ENDTX | ATMEL_US_TXBUFE)) {
-			UART_PUT_IDR(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
-			tasklet_schedule(&atmel_port->tasklet);
-		}
-	} else {
-		/* Interrupt transmit */
-		if (pending & ATMEL_US_TXRDY) {
-			UART_PUT_IDR(port, ATMEL_US_TXRDY);
-			tasklet_schedule(&atmel_port->tasklet);
-		}
+	if (pending & atmel_port->tx_done_mask) {
+		/* Either PDC or interrupt transmission */
+		UART_PUT_IDR(port, atmel_port->tx_done_mask);
+		tasklet_schedule(&atmel_port->tasklet);
 	}
 }
 

@@ -590,9 +708,15 @@ static void atmel_tx_dma(struct uart_port *port)
 
 		UART_PUT_TPR(port, pdc->dma_addr + xmit->tail);
 		UART_PUT_TCR(port, count);
-		/* re-enable PDC transmit and interrupts */
+		/* re-enable PDC transmit */
 		UART_PUT_PTCR(port, ATMEL_PDC_TXTEN);
-		UART_PUT_IER(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
+		/* Enable interrupts */
+		UART_PUT_IER(port, atmel_port->tx_done_mask);
+	} else {
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+			/* DMA done, stop TX, start RX for RS485 */
+			atmel_start_rx(port);
+		}
 	}
 
 	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)

@@ -1017,6 +1141,7 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 {
 	unsigned long flags;
 	unsigned int mode, imr, quot, baud;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
 	/* Get current mode register */
 	mode = UART_GET_MR(port) & ~(ATMEL_US_USCLKS | ATMEL_US_CHRL

@@ -1115,6 +1240,17 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
 	/* disable receiver and transmitter */
 	UART_PUT_CR(port, ATMEL_US_TXDIS | ATMEL_US_RXDIS);
 
+	/* Resetting serial mode to RS232 (0x0) */
+	mode &= ~ATMEL_US_USMODE;
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_before_send);
+		mode |= ATMEL_US_USMODE_RS485;
+	} else {
+		dev_dbg(port->dev, "Setting UART to RS232\n");
+	}
+
 	/* set the parity, stop bits and data size */
 	UART_PUT_MR(port, mode);
 

@@ -1231,6 +1367,28 @@ static void atmel_poll_put_char(struct uart_port *port, unsigned char ch)
 }
 #endif
 
+static int
+atmel_ioctl(struct uart_port *port, unsigned int cmd, unsigned long arg)
+{
+	struct serial_rs485 rs485conf;
+
+	switch (cmd) {
+	case TIOCSRS485:
+		if (copy_from_user(&rs485conf, (struct serial_rs485 *) arg,
+					sizeof(rs485conf)))
+			return -EFAULT;
+
+		atmel_config_rs485(port, &rs485conf);
+		break;
+
+	default:
+		return -ENOIOCTLCMD;
+	}
+	return 0;
+}
+
+
+
 static struct uart_ops atmel_pops = {
 	.tx_empty	= atmel_tx_empty,
 	.set_mctrl	= atmel_set_mctrl,

@@ -1250,6 +1408,7 @@ static struct uart_ops atmel_pops = {
 	.config_port	= atmel_config_port,
 	.verify_port	= atmel_verify_port,
 	.pm		= atmel_serial_pm,
+	.ioctl		= atmel_ioctl,
 #ifdef CONFIG_CONSOLE_POLL
 	.poll_get_char	= atmel_poll_get_char,
 	.poll_put_char	= atmel_poll_put_char,

@@ -1265,13 +1424,12 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
 	struct uart_port *port = &atmel_port->uart;
 	struct atmel_uart_data *data = pdev->dev.platform_data;
 
-	port->iotype	= UPIO_MEM;
-	port->flags	= UPF_BOOT_AUTOCONF;
-	port->ops	= &atmel_pops;
-	port->fifosize	= 1;
-	port->line	= pdev->id;
-	port->dev	= &pdev->dev;
-
+	port->iotype		= UPIO_MEM;
+	port->flags		= UPF_BOOT_AUTOCONF;
+	port->ops		= &atmel_pops;
+	port->fifosize		= 1;
+	port->line		= pdev->id;
+	port->dev		= &pdev->dev;
 	port->mapbase	= pdev->resource[0].start;
 	port->irq	= pdev->resource[1].start;
 

@@ -1299,8 +1457,16 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
 
 	atmel_port->use_dma_rx = data->use_dma_rx;
 	atmel_port->use_dma_tx = data->use_dma_tx;
-	if (atmel_use_dma_tx(port))
+	atmel_port->rs485	= data->rs485;
+	/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+		atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
+	else if (atmel_use_dma_tx(port)) {
 		port->fifosize = PDC_BUFFER_SIZE;
+		atmel_port->tx_done_mask = ATMEL_US_ENDTX | ATMEL_US_TXBUFE;
+	} else {
+		atmel_port->tx_done_mask = ATMEL_US_TXRDY;
+	}
 }
 
 /*

@@ -1334,6 +1500,7 @@ static void atmel_console_putchar(struct uart_port *port, int ch)
 static void atmel_console_write(struct console *co, const char *s, u_int count)
 {
 	struct uart_port *port = &atmel_ports[co->index].uart;
+	struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 	unsigned int status, imr;
 	unsigned int pdc_tx;
 

@@ -1341,7 +1508,7 @@ static void atmel_console_write(struct console *co, const char *s, u_int count)
 	 * First, save IMR and then disable interrupts
 	 */
 	imr = UART_GET_IMR(port);
-	UART_PUT_IDR(port, ATMEL_US_RXRDY | ATMEL_US_TXRDY);
+	UART_PUT_IDR(port, ATMEL_US_RXRDY | atmel_port->tx_done_mask);
 
 	/* Store PDC transmit status and disable it */
 	pdc_tx = UART_GET_PTSR(port) & ATMEL_PDC_TXTEN;

@@ -1355,7 +1522,7 @@ static void atmel_console_write(struct console *co, const char *s, u_int count)
 	 */
 	do {
 		status = UART_GET_CSR(port);
-	} while (!(status & ATMEL_US_TXRDY));
+	} while (!(status & atmel_port->tx_done_mask));
 
 	/* Restore PDC transmit status */
 	if (pdc_tx)

@@ -1587,7 +1754,7 @@ static int __devinit atmel_serial_probe(struct platform_device *pdev)
 	device_init_wakeup(&pdev->dev, 1);
 	platform_set_drvdata(pdev, port);
 
-	return 0;
+	return device_create_file(&(pdev->dev), &dev_attr_rs485);
 
 err_add_port:
 	kfree(port->rx_ring.buf);

@@ -1619,6 +1786,8 @@ static int __devexit atmel_serial_remove(struct platform_device *pdev)
 
 	clk_put(atmel_port->clk);
 
+	device_remove_file(&(pdev->dev), &dev_attr_rs485);
+
 	return ret;
 }
 

Quoted 13 lines · Claudio Scordino

Ryan Mallon ha scritto:

Quoted 10 lines

Quoted 8 lines · Claudio Scordino

Hi all,

this is the new version of the patch to add RS485 support to the atmel_serial driver. It's been changed according to Ryan Mallon's comments.

This new patch has been tested again (with and without DMA) by Sebastian Heutling (CC:-ed).

A few more, mostly nitpicky, comments below.

Hi Ryan,

Quoted 4 lines

many thanks for your feedback.

Please find attached a new version of the patch, modified according to your comments.

Looks good. You should add a Tested-by for Sebastian, and you can add:

Reviewed-by Ryan Mallon <[email protected]>

+#define TIOCSRS485 0x5461

+static DEVICE_ATTR(rs485, 0644, show_rs485, set_rs485);

NAK - assorted problems, notably locking ones caused by the sysfs stuff which should probably be dropped.

Quoted 1 line

+#define TIOCSRS485 0x5461

Please provide TIOCGRS485 as well

Review

Quoted 10 lines

(quoted diff) +10 -0

+static ssize_t show_rs485(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	struct platform_device *pdev = to_platform_device(dev);
+	struct uart_port *port = platform_get_drvdata(pdev);
+	unsigned int current_mode;
+
+	current_mode = UART_GET_MR(port) & ATMEL_US_USMODE;
+	return snprintf(buf, PAGE_SIZE, "%u\n", current_mode);
+}

You should have TIOCGRS485 for providing the info back as part of the API

Review

Quoted 3 lines

(quoted diff) +3 -0

+
+static ssize_t set_rs485(struct device *dev, struct device_attribute *attr,
+			  const char *buf, size_t len)

Expain the locking on this could you - I don't see what protects against parallel ioctl and sysfs stuff ?

Quoted 1 line

+static DEVICE_ATTR(rs485, 0644, show_rs485, set_rs485);

Why should this be public read ?

Review

Quoted 9 lines

(quoted diff) +9 -0

+	/* Resetting serial mode to RS232 (0x0) */
+	mode &= ~ATMEL_US_USMODE;
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
+		dev_dbg(port->dev, "Setting UART to RS485\n");
+		UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_before_send);
+		mode |= ATMEL_US_USMODE_RS485;
+	} else {
+		dev_dbg(port->dev, "Setting UART to RS232\n");

Locking versus sysfs ?

Review

Quoted 5 lines

(quoted diff) +4 -0

+	UART_PUT_IDR(port, atmel_port->tx_done_mask);
+
+	if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+		atmel_start_rx(port);
 }

Ditto

Review

Quoted 4 lines

(quoted diff) +3 -1

-		UART_PUT_IER(port, ATMEL_US_ENDTX | ATMEL_US_TXBUFE);
+		if (atmel_port->rs485.flags & SER_RS485_ENABLED)
+			atmel_stop_rx(port);
+

Ditto

Given the locking mess you are going to create I would suggest dropping the sysfs stuff.

Alan

Thank you for the feedback.

Let me know if this new version solves the above problems.

atmel_serial: Atmel RS485 support

Signed-off-by Claudio Scordino <[email protected]>

Signed-off-by Michael Trimarchi <[email protected]>

Signed-off-by Rick Bronson <[email protected]>

Signed-off-by Sebastian Heutling <[email protected]>

Tested-by Sebastian Heutling <[email protected]>

Reviewed-by Ryan Mallon <[email protected]>

Le 08/04/2010 15:16, Claudio Scordino :

[..]

Quoted 9 lines

atmel_serial: Atmel RS485 support

Signed-off-by Claudio Scordino <[email protected]>

Signed-off-by Michael Trimarchi <[email protected]>

Signed-off-by Rick Bronson <[email protected]>

Signed-off-by Sebastian Heutling <[email protected]>

Tested-by Sebastian Heutling <[email protected]>

Reviewed-by Ryan Mallon <[email protected]>

Even though I personally did not test this patch I think it is time to go forward with this very good work.

Considering the number of people involved in this testing and review I think that we can submit this patch for mainline. Who will handle it?
- do we submit to ARM or serial subsystem ?

Nicolas Ferre ha scritto:

Quoted 15 lines

Le 08/04/2010 15:16, Claudio Scordino :

[..]

Quoted 9 lines

atmel_serial: Atmel RS485 support

Signed-off-by Claudio Scordino <[email protected]>

Signed-off-by Michael Trimarchi <[email protected]>

Signed-off-by Rick Bronson <[email protected]>

Signed-off-by Sebastian Heutling <[email protected]>

Tested-by Sebastian Heutling <[email protected]>

Reviewed-by Ryan Mallon <[email protected]>

Quoted 7 lines

Even though I personally did not test this patch I think it is time to go forward with this very good work.

Considering the number of people involved in this testing and review I think that we can submit this patch for mainline. Who will handle it?
- do we submit to ARM or serial subsystem ?

Hi Nicolas,

the latest version of the patch has been already merged in the
latest Linus' git tree through Russell King's patchsystem

(the maintainer of the driver never answered to emails...).

Quoted 2 lines

the latest version of the patch has been already merged in the
latest Linus' git tree through Russell King's patchsystem

Hi Claudio,

kudos for getting a RS485-implementation into the kernel! Very useful.

Quoted 3 lines

Quoted 3 lines

the latest version of the patch has been already merged in the
latest Linus' git tree through Russell King's patchsystem

Nitpick: Wasn't there some documentation promised after the final patch ;)

Hi all,

some time ago I've been asked (by both Wolfram and Philippe) to
provide some minimal documentation about the usage of the RS485 interface.

Here is the document (updated with the very last changes in the interface).

Best regards,

Claudio

Documentation about RS485 serial communications.

Signed-off-by Claudio Scordino <[email protected]>

---
 Documentation/serial/00-INDEX         |    2 +
 Documentation/serial/serial-rs485.txt |  123 +++++++++++++++++++++++++++++++++
 2 files changed, 125 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/serial/serial-rs485.txt

Documentation/serial/00-INDEX +2 -0

index 07dcdb0..e09468a 100644
@@ -14,6 +14,8 @@ riscom8.txt
 	- notes on using the RISCom/8 multi-port serial driver.
 rocket.txt
 	- info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+	- info about RS485 structures and support in the kernel.
 specialix.txt
 	- info on hardware/driver for specialix IO8+ multiport serial card.
 stallion.txt

Documentation/serial/serial-rs485.txt new file +89 -0

new file mode 100644
index 0000000..f594831
@@ -0,0 +1,123 @@
+                        RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+   EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+   electrical characteristics of drivers and receivers for use in balanced
+   digital multipoint systems.
+   This standard is widely used for communications in industrial automation
+   because it can be used effectively over long distances and in electrically
+   noisy environments.
+   Even though the data is transmitted over a 2-wire twisted pair bus, all
+   EIA-485 transceivers interpret the voltage levels of the differential
+   signals with respect to a third common voltage. Without this common
+   reference, a set of transceivers may interpret the differential signals
+   incorrectly.
+   See [1] for more information.
+
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+   Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
+   as RS232 and RS485. For these microcontrollers, the Linux driver should be
+   able of working in both modes, and proper ioctls (see later) should be made
+   available at user-level to allow switching from one mode to the other, and
+   viceversa.
+
+   On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
+   integrated inside the microcontroller itself. Therefore, manufacturers who
+   use these microcontrollers to produce embedded boards need to connect an
+   external transceiver to some pin of the CPU.
+   On these architectures, therefore, no assumptions can be done at the
+   CPU-level about the presence of a RS485 transceiver, because the connection
+   (if any) is done outside the microcontroller. Moreover, even in case of
+   RS485 transceiver, the manufacturer is free to choose the CPU pin used for
+   the connection.
+
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+   The Linux kernel provides the serial_rs485 structure (see [2]) to handle
+   RS485 communications. This data structure is used to set and configure RS485
+   parameters in the platform data and in ioctls.
+
+   Any driver for devices capable of working both as RS232 and RS485 should
+   provide at least the following ioctls:
+
+    - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+      to enable/disable RS485 mode from user-space
+
+    - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+      to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+   In other words, the serial driver should contain a code similar to the next
+   one:
+
+	static struct uart_ops atmel_pops = {
+		/* ... */
+		.ioctl		= handle_ioctl,
+	};
+
+	static int handle_ioctl(struct uart_port *port,
+		unsigned int cmd,
+		unsigned long arg)
+	{
+		struct serial_rs485 rs485conf;
+
+		switch (cmd) {
+			case TIOCSRS485:
+				if (copy_from_user(&rs485conf,
+					(struct serial_rs485 *) arg,
+					sizeof(rs485conf)))
+						return -EFAULT;
+
+				/* ... */
+				break;
+
+			case TIOCGRS485:
+				if (copy_to_user((struct serial_rs485 *) arg,
+					...,
+					sizeof(rs485conf)))
+						return -EFAULT;
+				/* ... */
+				break;
+
+			/* ... */
+		}
+	}
+
+

Documentation/serial/serial-rs485.txt new file +7 -0

+
+	/* Open specific device: */
+	int fd = open ("/dev/mydevice", O_RDWR);
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;

Documentation/serial/serial-rs485.txt new file +7 -0

+
+	close (fd);
+
+5. REFERENCES
+
+ [1]	http://en.wikipedia.org/wiki/Rs485
+ [2]	include/linux/serial.h

Signature · 1 line

1.6.0.4

Hi all,

some time ago I've been asked (by both Wolfram and Philippe) to
provide some minimal documentation about the usage of the RS485 interface.

Here is the document (updated with the very last changes in the interface).

Best regards,

Claudio

Documentation about RS485 serial communications.

Signed-off-by Claudio Scordino <[email protected]>

---
 Documentation/serial/00-INDEX         |    2 +
 Documentation/serial/serial-rs485.txt |  123 +++++++++++++++++++++++++++++++++
 2 files changed, 125 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/serial/serial-rs485.txt

Documentation/serial/serial-rs485.txt new file +2 -0

new file mode 100644
index 0000000..f594831
@@ -0,0 +1,123 @@
+                        RS485 SERIAL COMMUNICATIONS
+

Documentation/serial/serial-rs485.txt new file +16 -0

+
+   On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
+   integrated inside the microcontroller itself. Therefore, manufacturers who
+   use these microcontrollers to produce embedded boards need to connect an
+   external transceiver to some pin of the CPU.
+   On these architectures, therefore, no assumptions can be done at the
+   CPU-level about the presence of a RS485 transceiver, because the connection
+   (if any) is done outside the microcontroller. Moreover, even in case of
+   RS485 transceiver, the manufacturer is free to choose the CPU pin used for
+   the connection.
+
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+   The Linux kernel provides the serial_rs485 structure (see [2]) to handle
+   RS485 communications. This data structure is used to set and configure RS485

+ In other words, the serial driver should contain a code similar to the next

Documentation/serial/serial-rs485.txt new file +5 -0

+   one:
+
+	static struct uart_ops atmel_pops = {
+		/* ... */
+		.ioctl		= handle_ioctl,

Documentation/serial/serial-rs485.txt new file +32 -0

+				if (copy_from_user(&rs485conf,
+					(struct serial_rs485 *) arg,
+					sizeof(rs485conf)))
+						return -EFAULT;
+
+				/* ... */
+				break;
+
+			case TIOCGRS485:
+				if (copy_to_user((struct serial_rs485 *) arg,
+					...,
+					sizeof(rs485conf)))
+						return -EFAULT;
+				/* ... */
+				break;
+
+			/* ... */
+		}
+	}
+
+
+4. USAGE FROM USER-LEVEL
+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+

TIOC[SG]RS485 are #defined in <asm-generic/ioctls.h>, so #include <asm-generic/ioctls.h>
here and/or below (in userspace program).

Quoted 7 lines

Hi all,

some time ago I've been asked (by both Wolfram and Philippe) to
provide some minimal documentation about the usage of the RS485 interface.

Thanks for the addition.

Randy Dunlap ha scritto:

Quoted 8 lines · On Wed, 11 Aug 2010 11:26:23 +0200 Claudio Scordino wrote:

Quoted 7 lines

Hi all,

some time ago I've been asked (by both Wolfram and Philippe) to
provide some minimal documentation about the usage of the RS485 interface.

[...]

Quoted 1 line

Quoted 2 lines

Thanks for the addition.

Hi all,

here is the document about RS485 with the requested additions.

If OK, somebody please provide for merging.

Best regards,

Claudio

Documentation about RS485 serial communications.

Signed-off-by Claudio Scordino <[email protected]>

---
 Documentation/serial/00-INDEX         |    2 +
 Documentation/serial/serial-rs485.txt |  126 +++++++++++++++++++++++++++++++++
 2 files changed, 128 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/serial/serial-rs485.txt

Documentation/serial/00-INDEX +2 -0

index 07dcdb0..e09468a 100644
@@ -14,6 +14,8 @@ riscom8.txt
 	- notes on using the RISCom/8 multi-port serial driver.
 rocket.txt
 	- info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+	- info about RS485 structures and support in the kernel.
 specialix.txt
 	- info on hardware/driver for specialix IO8+ multiport serial card.
 stallion.txt

Documentation/serial/serial-rs485.txt new file +126 -0

new file mode 100644
index 0000000..93b029e
@@ -0,0 +1,126 @@
+                        RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+   EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+   electrical characteristics of drivers and receivers for use in balanced
+   digital multipoint systems.
+   This standard is widely used for communications in industrial automation
+   because it can be used effectively over long distances and in electrically
+   noisy environments.
+   Even though the data is transmitted over a 2-wire twisted pair bus, all
+   EIA-485 transceivers interpret the voltage levels of the differential
+   signals with respect to a third common voltage. Without this common
+   reference, a set of transceivers may interpret the differential signals
+   incorrectly.
+   See [1] for more information.
+
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+   Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working both
+   as RS232 and RS485. For these microcontrollers, the Linux driver should be
+   made capable of working in both modes, and proper ioctls (see later) should
+   be made available at user-level to allow switching from one mode to the
+   other, and vice versa.
+
+   On some other CPUs (e.g., Freescale imx25) the RS485 transceiver is not
+   integrated inside the microcontroller itself. Therefore, manufacturers who
+   use these microcontrollers to produce embedded boards need to connect an
+   external transceiver to some pin of the CPU.
+   On these architectures, therefore, no assumptions can be done at the
+   CPU-level about the presence of a RS485 transceiver, because the connection
+   (if any) is done outside the microcontroller. Moreover, even in case of
+   RS485 transceiver, the manufacturer is free to choose the CPU pin used for
+   the connection.
+
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+   The Linux kernel provides the serial_rs485 structure (see [2]) to handle
+   RS485 communications. This data structure is used to set and configure RS485
+   parameters in the platform data and in ioctls.
+
+   Any driver for devices capable of working both as RS232 and RS485 should
+   provide at least the following ioctls:
+
+    - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+      to enable/disable RS485 mode from user-space
+
+    - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+      to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+   In other words, the serial driver should contain a code similar to the next
+   one:
+
+	static struct uart_ops atmel_pops = {
+		/* ... */
+		.ioctl		= handle_ioctl,
+	};
+
+	static int handle_ioctl(struct uart_port *port,
+		unsigned int cmd,
+		unsigned long arg)
+	{
+		struct serial_rs485 rs485conf;
+
+		switch (cmd) {
+		case TIOCSRS485:
+			if (copy_from_user(&rs485conf,
+				(struct serial_rs485 *) arg,
+				sizeof(rs485conf)))
+					return -EFAULT;
+
+			/* ... */
+			break;
+
+		case TIOCGRS485:
+			if (copy_to_user((struct serial_rs485 *) arg,
+				...,
+				sizeof(rs485conf)))
+					return -EFAULT;
+			/* ... */
+			break;
+
+		/* ... */
+		}
+	}
+
+
+4. USAGE FROM USER-LEVEL
+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;
+
+	/* Set rts delay before send, if needed: */
+	rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+	rs485conf.delay_rts_before_send = ...;
+
+	/* Set rts delay after send, if needed: */
+	rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+	rs485conf.delay_rts_after_send = ...;
+
+	ioctl (fd, TIOCSRS485, &rs485conf);
+
+	/* Use read() and write() syscalls here... */
+
+	/* Close the device when finished: */
+	close (fd);
+
+5. REFERENCES
+
+ [1]	http://en.wikipedia.org/wiki/Rs485
+ [2]	include/linux/serial.h

Quoted 14 lines · Claudio Scordino

Documentation/serial/serial-rs485.txt new file +8 -0

new file mode 100644
index 0000000..93b029e
@@ -0,0 +1,126 @@
+                        RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+   EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+   electrical characteristics of drivers and receivers for use in balanced
+   digital multipoint systems.
+   This standard is widely used for communications in industrial automation

Documentation/serial/serial-rs485.txt line 16

Quoted 8 lines

Documentation/serial/serial-rs485.txt new file +8 -0

+   because it can be used effectively over long distances and in electrically
+   noisy environments.
+   Even though the data is transmitted over a 2-wire twisted pair bus, all
+   EIA-485 transceivers interpret the voltage levels of the differential
+   signals with respect to a third common voltage. Without this common
+   reference, a set of transceivers may interpret the differential signals
+   incorrectly.
+   See [1] for more information.

Quoted 19 lines

Documentation/serial/serial-rs485.txt new file +19 -0

+4. USAGE FROM USER-LEVEL
+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;
+
+	/* Set rts delay before send, if needed: */

Documentation/serial/serial-rs485.txt line 116

Quoted 8 lines

Documentation/serial/serial-rs485.txt new file +8 -0

+	rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+	rs485conf.delay_rts_before_send = ...;
+
+	/* Set rts delay after send, if needed: */
+	rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+	rs485conf.delay_rts_after_send = ...;
+
+	ioctl (fd, TIOCSRS485, &rs485conf);

Quoted 10 lines

Documentation/serial/serial-rs485.txt new file +10 -0

+
+	/* Use read() and write() syscalls here... */
+
+	/* Close the device when finished: */
+	close (fd);
+
+5. REFERENCES
+
+ [1]	http://en.wikipedia.org/wiki/Rs485
+ [2]	include/linux/serial.h

Quoted 15 lines · Claudio Scordino

Quoted 14 lines

Documentation/serial/serial-rs485.txt new file +8 -0

new file mode 100644
index 0000000..93b029e
@@ -0,0 +1,126 @@
+                        RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+   EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+   electrical characteristics of drivers and receivers for use in balanced
+   digital multipoint systems.
+   This standard is widely used for communications in industrial automation

Quoted 8 lines

Documentation/serial/serial-rs485.txt line 16

Quoted 8 lines

Documentation/serial/serial-rs485.txt new file +8 -0

+   because it can be used effectively over long distances and in electrically
+   noisy environments.
+   Even though the data is transmitted over a 2-wire twisted pair bus, all
+   EIA-485 transceivers interpret the voltage levels of the differential
+   signals with respect to a third common voltage. Without this common
+   reference, a set of transceivers may interpret the differential signals
+   incorrectly.
+   See [1] for more information.

There are devices on the market which are fully isolating RS485 transceivers which just take the A/B connections, measuring the differential voltage, and provide you with the TXD/RXD TTL signals for your UART.

Also note that [1] appears a little confused about the number of pins required for RS485 - it says two, and then lists three pins. I don't think you can use this as being supportive of the requirement for three connections - and as there are these fully isolating transceivers...

Quoted 23 lines

Quoted 23 lines

Documentation/serial/serial-rs485.txt new file +23 -0

+4. USAGE FROM USER-LEVEL
+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;
+
+	/* Set rts delay before send, if needed: */
+	rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+	rs485conf.delay_rts_before_send = ...;
+
+	/* Set rts delay after send, if needed: */

Quoted 4 lines

Documentation/serial/serial-rs485.txt line 43

Quoted 4 lines

Documentation/serial/serial-rs485.txt new file +4 -0

+	rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+	rs485conf.delay_rts_after_send = ...;
+
+	ioctl (fd, TIOCSRS485, &rs485conf);

Example code really should do things right, such as check for error conditions - otherwise people will copy'n'paste this and assume that the ioctl never fails.

Quoted 4 lines · Claudio Scordino

+2. HARDWARE-RELATED CONSIDERATIONS

(quoted diff) +2 -0

+
+   Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working

both + as RS232 and RS485.

Pardon my curiosity, but I've looked at a few AT91 parts, and I've never seen on with an internal transceiver -- nor does Google seem able to find any.

Frankly, I'd be pretty surprised, since it would be very difficult (fab-wise), to build a mircoprocessor with I/O cells capable of withstanding the voltage levels specified in RS232.

Can you specify to which parts you're referring?

Quoted 14 lines · On Tuesday 19 October 2010, 16:29:48 Grant Edwards wrote:

Quoted 4 lines · Claudio Scordino

+2. HARDWARE-RELATED CONSIDERATIONS

(quoted diff) +2 -0

+
+   Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working

both + as RS232 and RS485.

Pardon my curiosity, but I've looked at a few AT91 parts, and I've never seen on with an internal transceiver -- nor does Google seem able to find any.

Frankly, I'd be pretty surprised, since it would be very difficult (fab-wise), to build a mircoprocessor with I/O cells capable of withstanding the voltage levels specified in RS232.

Quoted 1 line

Can you specify to which parts you're referring?

I doubt the AT91 do have an internal transceiver but it has a dedicated pin feature (RTS or CTS or something) which can be used to switch between RS232 and RS485 by setting a bit in the USART provided the pin is connected properly.

Quoted 15 lines · On Tuesday 19 October 2010, 16:29:48 Grant Edwards wrote:

Quoted 14 lines · Claudio Scordino

Quoted 4 lines

+2. HARDWARE-RELATED CONSIDERATIONS

(quoted diff) +2 -0

+
+   Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working

both + as RS232 and RS485.

Pardon my curiosity, but I've looked at a few AT91 parts, and I've never seen on with an internal transceiver -- nor does Google seem able to find any.

Frankly, I'd be pretty surprised, since it would be very difficult (fab-wise), to build a mircoprocessor with I/O cells capable of withstanding the voltage levels specified in RS232.

Quoted 6 lines

Quoted 1 line

Can you specify to which parts you're referring?

I doubt the AT91 do have an internal transceiver but it has a dedicated pin feature (RTS or CTS or something) which can be used to switch between RS232 and RS485 by setting a bit in the USART provided the pin is connected properly.

Yes, the AT91 UARTs do have a built-in half-duplex mode that will automatically control line direction by toggling RTS.

That can used to control external half-duplex hardware like an RS485 transceiver or any RS232-connected half-duplex device like some modems.

Though the Atmel docs refer to it as "RS485 mode" there is no RS485 transceiver in the AT91 parts (AFAIK), and "RS485 mode" isn't specific to RS485 - it can be used with any external half-duplex hardware.

Yes, the AT91 UARTs do have a built-in half-duplex mode that will automatically control line direction by toggling RTS.

That can used to control external half-duplex hardware like an RS485 transceiver or any RS232-connected half-duplex device like some modems.

Though the Atmel docs refer to it as "RS485 mode" there is no RS485 transceiver in the AT91 parts (AFAIK), and "RS485 mode" isn't specific to RS485 - it can be used with any external half-duplex hardware.

Quoted 7 lines · On Tuesday 19 October 2010, 19:22:32 Grant Edwards wrote:

Yes, the AT91 UARTs do have a built-in half-duplex mode that will automatically control line direction by toggling RTS.

That can used to control external half-duplex hardware like an RS485 transceiver or any RS232-connected half-duplex device like some modems.

Quoted 3 lines

Though the Atmel docs refer to it as "RS485 mode" there is no RS485 transceiver in the AT91 parts (AFAIK), and "RS485 mode" isn't specific to RS485 - it can be used with any external half-duplex hardware.

Out of curiosity, how can I add RS485 (or whatever) support for other serial devices like e.g. i.mx serial? Is there some driver independent interface which only gets filled in board configs like setting some GPIO pins?

Quoted 14 lines · On Tuesday 19 October 2010, 16:29:48 Grant Edwards wrote:

Quoted 13 lines · Claudio Scordino

Quoted 4 lines

+2. HARDWARE-RELATED CONSIDERATIONS

(quoted diff) +2 -0

+
+   Some CPUs (e.g., Atmel AT91) contain a transceiver capable of working

both + as RS232 and RS485.

Pardon my curiosity, but I've looked at a few AT91 parts, and I've never seen on with an internal transceiver -- nor does Google seem able to find any.

Frankly, I'd be pretty surprised, since it would be very difficult (fab-wise), to build a mircoprocessor with I/O cells capable of withstanding the voltage levels specified in RS232.

Quoted 5 lines

Quoted 1 line

Can you specify to which parts you're referring?

I doubt the AT91 do have an internal transceiver but it has a dedicated pin feature (RTS or CTS or something) which can be used to switch between RS232 and RS485 by setting a bit in the USART provided the pin is connected properly.

Yes, the AT91 UARTs do have a built-in half-duplex mode that will automatically control line direction by toggling RTS.

That can used to control external half-duplex hardware like an RS485 transceiver or any RS232-connected half-duplex device like some modems.

Though the Atmel docs refer to it as "RS485 mode" there is no RS485 transceiver in the AT91 parts (AFAIK), and "RS485 mode" isn't specific to RS485 - it can be used with any external half-duplex hardware.

+4. USAGE FROM USER-LEVEL

Documentation/serial/serial-rs485.txt new file +12 -0

+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);

Just a minor issue.

Quoted 13 lines · Claudio Scordino

+4. USAGE FROM USER-LEVEL

Documentation/serial/serial-rs485.txt new file +12 -0

+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);

Documentation/serial/serial-rs485.txt line 98

Quoted 10 lines

Documentation/serial/serial-rs485.txt new file +10 -0

+	if (fd < 0) {
+		/* Error handling. See errno. */
+	}
+
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;
+
+	/* Set rts delay before send, if needed: */

This comment is misleading as the delay must be set regardless. If it is not used it should be set to 0.

Documentation/serial/serial-rs485.txt line 100

Quoted 2 lines

Documentation/serial/serial-rs485.txt new file +2 -0

+	rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+	rs485conf.delay_rts_before_send = ...;

Chris Down ha scritto:

Quoted 29 lines

Just a minor issue.

Quoted 13 lines · Claudio Scordino

+4. USAGE FROM USER-LEVEL

Documentation/serial/serial-rs485.txt new file +12 -0

+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);

Documentation/serial/serial-rs485.txt line 98

Quoted 10 lines

Documentation/serial/serial-rs485.txt new file +10 -0

+	if (fd < 0) {
+		/* Error handling. See errno. */
+	}
+
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;
+
+	/* Set rts delay before send, if needed: */

This comment is misleading as the delay must be set regardless. If it is not used it should be set to 0.

Quoted 2 lines

Documentation/serial/serial-rs485.txt line 100

Quoted 2 lines

Documentation/serial/serial-rs485.txt new file +2 -0

+	rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+	rs485conf.delay_rts_before_send = ...;

Hi.

What do you mean ?

The delay has not to be set regardless: if the SER_RS485_RTS_BEFORE_SEND flag is not set, then the value of delay_rts_before_send is ignored, whatever value is contained.

In other words, the value of delay_rts_before_send is used only when SER_RS485_RTS_BEFORE_SEND is set.

If you don't need a delay, you have to unset the SER_RS485_RTS_BEFORE_SEND flag rather than setting a delay equal to 0...

Best regards,

Claudio

Hi all,

sorry for the misuse of the term "transceiver", and thank you
for your corrections.

Hopefully, this new version of the document is slightly better.

Many thanks,

Claudio

Documentation about RS485 serial communications

Signed-off-by Claudio Scordino <[email protected]>

---
 Documentation/serial/00-INDEX         |    2 +
 Documentation/serial/serial-rs485.txt |  119 +++++++++++++++++++++++++++++++++
 2 files changed, 121 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/serial/serial-rs485.txt

Documentation/serial/00-INDEX +2 -0

index 07dcdb0..e09468a 100644
@@ -14,6 +14,8 @@ riscom8.txt
 	- notes on using the RISCom/8 multi-port serial driver.
 rocket.txt
 	- info on the Comtrol RocketPort multiport serial driver.
+serial-rs485.txt
+	- info about RS485 structures and support in the kernel.
 specialix.txt
 	- info on hardware/driver for specialix IO8+ multiport serial card.
 stallion.txt

Documentation/serial/serial-rs485.txt new file +119 -0

new file mode 100644
index 0000000..40f09c6
@@ -0,0 +1,119 @@
+                        RS485 SERIAL COMMUNICATIONS
+
+1. INTRODUCTION
+
+   EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
+   electrical characteristics of drivers and receivers for use in balanced
+   digital multipoint systems.
+   This standard is widely used for communications in industrial automation
+   because it can be used effectively over long distances and in electrically
+   noisy environments.
+
+2. HARDWARE-RELATED CONSIDERATIONS
+
+   Some CPUs (e.g., Atmel AT91) contain a built-in half-duplex mode capable of
+   automatically controlling line direction by toggling RTS. That can used to
+   control external half-duplex hardware like an RS485 transceiver or any
+   RS232-connected half-duplex device like some modems.
+
+   For these microcontrollers, the Linux driver should be made capable of
+   working in both modes, and proper ioctls (see later) should be made
+   available at user-level to allow switching from one mode to the other, and
+   vice versa.
+
+3. DATA STRUCTURES ALREADY AVAILABLE IN THE KERNEL
+
+   The Linux kernel provides the serial_rs485 structure (see [1]) to handle
+   RS485 communications. This data structure is used to set and configure RS485
+   parameters in the platform data and in ioctls.
+
+   Any driver for devices capable of working both as RS232 and RS485 should
+   provide at least the following ioctls:
+
+    - TIOCSRS485 (typically associated with number 0x542F). This ioctl is used
+      to enable/disable RS485 mode from user-space
+
+    - TIOCGRS485 (typically associated with number 0x542E). This ioctl is used
+      to get RS485 mode from kernel-space (i.e., driver) to user-space.
+
+   In other words, the serial driver should contain a code similar to the next
+   one:
+
+	static struct uart_ops atmel_pops = {
+		/* ... */
+		.ioctl		= handle_ioctl,
+	};
+
+	static int handle_ioctl(struct uart_port *port,
+		unsigned int cmd,
+		unsigned long arg)
+	{
+		struct serial_rs485 rs485conf;
+
+		switch (cmd) {
+		case TIOCSRS485:
+			if (copy_from_user(&rs485conf,
+				(struct serial_rs485 *) arg,
+				sizeof(rs485conf)))
+					return -EFAULT;
+
+			/* ... */
+			break;
+
+		case TIOCGRS485:
+			if (copy_to_user((struct serial_rs485 *) arg,
+				...,
+				sizeof(rs485conf)))
+					return -EFAULT;
+			/* ... */
+			break;
+
+		/* ... */
+		}
+	}
+
+
+4. USAGE FROM USER-LEVEL
+
+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+
+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);
+	if (fd < 0) {
+		/* Error handling. See errno. */
+	}
+
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;
+
+	/* Set rts delay before send, if needed: */
+	rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
+	rs485conf.delay_rts_before_send = ...;
+
+	/* Set rts delay after send, if needed: */
+	rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
+	rs485conf.delay_rts_after_send = ...;
+
+	if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) {
+		/* Error handling. See errno. */
+	}
+
+	/* Use read() and write() syscalls here... */
+
+	/* Close the device when finished: */
+	if (close (fd) < 0) {
+		/* Error handling. See errno. */
+	}
+
+5. REFERENCES
+
+ [1]	include/linux/serial.h

Le 24/10/2010 13:29, Claudio Scordino :

[..]

Quoted 6 lines

Hi all,

sorry for the misuse of the term "transceiver", and thank you
for your corrections.

Hopefully, this new version of the document is slightly better.

Hi all,

This documentation is floating around for some time now. Claudio has enhanced it and it is maybe time to merge it in mainline...

So, can serial people include it in their tree (Greg?) or should it go through another path?

Quoted 12 lines

Le 24/10/2010 13:29, Claudio Scordino :

[..]

Quoted 6 lines

Hi all,

sorry for the misuse of the term "transceiver", and thank you
for your corrections.

Hopefully, this new version of the document is slightly better.

Hi all,

Quoted 5 lines

This documentation is floating around for some time now. Claudio has enhanced it and it is maybe time to merge it in mainline...

So, can serial people include it in their tree (Greg?) or should it go through another path?

I can take it, if someone resends it with the accumulated acks that I think it gathered over the review cycle.

Documentation about RS485 serial communications

Documentation/serial/serial-rs485.txt new file +9 -0

+   From user-level, RS485 configuration can be get/set using the previous
+   ioctls. For instance, to set RS485 you can use the following code:
+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+

Hi!

Quoted 1 line

Documentation about RS485 serial communications

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

Quoted 1 line

Documentation about RS485 serial communications

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Pavel Machek
Sent: Tuesday, November 16, 2010 3:30 PM
To: Claudio Scordino
Cc: Greg KH; Nicolas Ferre; [email protected]; Grant Edwards;
[email protected]; [email protected]; Alan
Cox
Subject: Re: [PATCH] Documentation about RS485 serial communications

Hi!

Quoted 1 line

Documentation about RS485 serial communications

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

Quoted 1 line

+ From user-level, RS485 configuration can be get/set

using the previous

Quoted 1 line

+ ioctls. For instance, to set RS485 you can use the

following code:

Quoted 7 lines

Documentation/serial/serial-rs485.txt new file +7 -0

+
+	#include <linux/serial.h>
+
+	/* Driver-specific ioctls: */
+	#define TIOCGRS485      0x542E
+	#define TIOCSRS485      0x542F
+

Documentation/serial/serial-rs485.txt line 96

Quoted 10 lines

Documentation/serial/serial-rs485.txt new file +10 -0

+	/* Open your specific device (e.g., /dev/mydevice): */
+	int fd = open ("/dev/mydevice", O_RDWR);
+	if (fd < 0) {
+		/* Error handling. See errno. */
+	}
+
+	struct serial_rs485 rs485conf;
+
+	/* Set RS485 mode: */
+	rs485conf.flags |= SER_RS485_ENABLED;

IOW... is this supposed to switch electrical levels?

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

I believe it is neither common nor a good thing.

Dynamically switching between electrical levels means that the remote device must be capable of handling both electrical levels, else it might be damaged (i.e., when the serial card is configured to RS485 but switches to RS232 when reset).

Or, different pins must be used for RS232 and RS485 (then software switching is not really useful).

Hi!

Quoted 1 line

Documentation about RS485 serial communications

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

Quoted 4 lines · Pavel Machek

Hi!

Quoted 1 line

Documentation about RS485 serial communications

Quoted 4 lines

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

In my opinion this type of card is not that common. Generally speaking the achievable baud rates for this type of multi-protocol card are very limited because of limitations of the transceiver chips.

It seems that most of the time people would rather have a faster serial port than one that does several different voltages.

Quoted 5 lines · Matt Schulte

Quoted 4 lines · Pavel Machek

Hi!

Quoted 1 line

Documentation about RS485 serial communications

Quoted 8 lines

Quoted 4 lines

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

In my opinion this type of card is not that common. ?Generally speaking the achievable baud rates for this type of multi-protocol card are very limited because of limitations of the transceiver chips.

I'm curious which selectable interface cards you're talking about that are slow? ?The ones I'm familiar with generally support baud rates up to either 460K bps or 921K bps

Quoted 2 lines

It seems that most of the time people would rather have a faster serial port than one that does several different voltages.

Where did you find a selectable interface serial card that couldn't support high baud rates?

Quoted 9 lines

Quoted 4 lines

In my opinion this type of card is not that common. ?Generally speaking the achievable baud rates for this type of multi-protocol card are very limited because of limitations of the transceiver chips.

I'm curious which selectable interface cards you're talking about that are slow? ?The ones I'm familiar with generally support baud rates up to either 460K bps or 921K bps

Quoted 5 lines

Quoted 2 lines

It seems that most of the time people would rather have a faster serial port than one that does several different voltages.

Where did you find a selectable interface serial card that couldn't support high baud rates?

In my world 460kbps for an RS422 card is slow. RS422 cards generally push multi megabit/s rates.

Quoted 7 lines · Pavel Machek

Hi!

Quoted 1 line

Documentation about RS485 serial communications

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Quoted 1 line

Is such hw common? If so, should we have standard interface?

In my opinion this type of card is not that common. Generally speaking the achievable baud rates for this type of multi-protocol card are very limited because of limitations of the transceiver chips.
It seems that most of the time people would rather have a faster
serial port than one that does several different voltages

Quoted 10 lines · On Tue, 16 Nov 2010 10:13:22 -0600 Matt Schulte <[email protected]>…

Quoted 8 lines · Pavel Machek

Hi!

Quoted 1 line

Documentation about RS485 serial communications

I have seen hardware (kontron pmc-6l) that was capable of switching between RS232, RS485 and one other standard by software.

Is such hw common? If so, should we have standard interface?

Quoted 5 lines

In my opinion this type of card is not that common. Generally speaking the achievable baud rates for this type of multi-protocol card are very limited because of limitations of the transceiver chips.
It seems that most of the time people would rather have a faster
serial port than one that does several different voltages

If there are two types in common use then thats enough to say we should have a common interface IMHO

Comtrol, Moxa, B&B, Sealevel, and others all sell PCI cards and Ethernet attached serial ports that have selectable interfaces (typically RS-232/422/485). Comtrol and Moxa have had drivers in the kernel tree for ages, but they've always had to use custom ioctl calls for things like configuring 232/485/422 mode and half/full-duplex mode.

Having a standard API for things like interface mode, half-full duplex, inter-character timeout, 9-bit mode, and so on would be life a lot easier for those of us who maintain Linux serial drivers...

Quoted 6 lines

Comtrol, Moxa, B&B, Sealevel, and others all sell PCI cards and Ethernet attached serial ports that have selectable interfaces (typically RS-232/422/485). Comtrol and Moxa have had drivers in the kernel tree for ages, but they've always had to use custom ioctl calls for things like configuring 232/485/422 mode and half/full-duplex mode.

Ok so what is needed that isn't covered by the current termiox and TIOCG/SRS485 ioctls ?

Quoted 3 lines

Having a standard API for things like interface mode, half-full duplex, inter-character timeout, 9-bit mode, and so on would be life a lot easier for those of us who maintain Linux serial drivers...

9bit mode is a real problem with the tty layer defined in terms of 8bit streams but yes.

Quoted 1 line

(the maintainer of the driver never answered to emails...).

I was supposed to take over its maintainance one year ago but did not find time to do it. My fault here also...

I take over the maintenance of SPI, USART, Ethernet and USB gadget drivers. Those drivers are found in Atmel microcontrollers, both AT32/AVR32 and AT91/ARM.

Signed-off-by Nicolas Ferre <[email protected]>

---
Haavard,
I finally change the MAINTAINERS entries for all drivers that you were taking care of. I must admit that I was a bit frighten at the first place but anyway, since one year, I am getting used to it ;-)

I take over the maintenance of SPI, USART, Ethernet and USB gadget drivers. Those drivers are found in Atmel microcontrollers, both AT32/AVR32 and AT91/ARM.

Signed-off-by Nicolas Ferre <[email protected]>

---
Haavard,
I finally change the MAINTAINERS entries for all drivers that you were taking care of. I must admit that I was a bit frighten at the first place but anyway, since one year, I am getting used to it ;-)

 MAINTAINERS |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

MAINTAINERS +5 -5

index 33047a6..d9ce9c6 100644
@@ -1148,7 +1148,7 @@ F:	drivers/mmc/host/atmel-mci.c
 F:	drivers/mmc/host/atmel-mci-regs.h
 
 ATMEL AT91 / AT32 SERIAL DRIVER
-M:	Haavard Skinnemoen <[email protected]>
+M:	Nicolas Ferre <[email protected]>
 S:	Supported
 F:	drivers/serial/atmel_serial.c
 

@@ -1160,18 +1160,18 @@ F:	drivers/video/atmel_lcdfb.c
 F:	include/video/atmel_lcdc.h
 
 ATMEL MACB ETHERNET DRIVER
-M:	Haavard Skinnemoen <[email protected]>
+M:	Nicolas Ferre <[email protected]>
 S:	Supported
 F:	drivers/net/macb.*
 
 ATMEL SPI DRIVER
-M:	Haavard Skinnemoen <[email protected]>
+M:	Nicolas Ferre <[email protected]>
 S:	Supported
 F:	drivers/spi/atmel_spi.*
 
 ATMEL USBA UDC DRIVER
-M:	Haavard Skinnemoen <[email protected]>
-L:	kernel at avr32linux.org
+M:	Nicolas Ferre <[email protected]>
+L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
 W:	http://avr32linux.org/twiki/bin/view/Main/AtmelUsbDeviceDriver
 S:	Supported
 F:	drivers/usb/gadget/atmel_usba_udc.*