kernel.git/drivers/tty/serial/imx.c, branch linux-4.11.y

serial: imx: Fix the CTS_B polarity in RS485 mode

2017-01-31T09:54:58Z

When userspace passes the SER_RS485_RTS_ON_SEND flag it means that the CTS_B pin should go to logic level high before the transmission begins. CTS_B goes to logic level high when both CTSC and CTS bits are cleared. When userspace passes the SER_RS485_RTS_AFTER_SEND flag it means that the CTS_B pin should go to logic level low after the transmission finishes. CTS_B goes to logic level low when CTSC bit is cleared and CTS bit is set. So fix the CTS_B polarity logic. Signed-off-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman

serial: imx: Fix the RTS GPIO polarity in RS485 mode

2017-01-31T09:54:58Z

On a board that needs to drive RTS GPIO high in order to enable the transmission of a RS485 transceiver the following description is passed in the devide tree: &uart4 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart4>; rts-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>; status = "okay"; }; and userspace configures the uart port as follows: /* enable RS485 mode: */ rs485conf.flags |= SER_RS485_ENABLED; /* set logical level for RTS pin equal to 1 when sending: */ rs485conf.flags |= SER_RS485_RTS_ON_SEND; /* set logical level for RTS pin equal to 0 after sending: */ rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND); However the RTS GPIO polarity observed in the oscilloscope is inverted. When the SER_RS485_RTS_ON_SEND flag is set the imx_port_rts_active() function should be called and following the same logic when SER_RS485_RTS_AFTER_SEND flag is cleared the imx_port_rts_inactive() should be called. Do such logic change so that RS485 communication in half duplex can work successfully when the RTS GPIO pin is passed via device tree. Signed-off-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman

serial: imx: Allow passing 'rst-gpios' for rs485 mode

2017-01-12T10:51:25Z

According to Documentation/devicetree/bindings/serial/serial.txt the generic 'rts-gpios' property can be used to specify the GPIO for RTS functionality. Currently it is not possible to use the imx UART port in rs485 mode when the 'rts-gpios' property is passed in the device tree. The imx uart driver only checks for the presence of the built-in RTS pin, via 'uart-has-rtscts' property and disable the rs485 flag if this property is absent. So fix this logic by also checking if RTS pin has been passed via GPIO. Tested on a imx6dl based board. Signed-off-by: Fabio Estevam Tested-by: Clemens Gruber Signed-off-by: Greg Kroah-Hartman

serial: imx: Fix DCD reading

2016-09-27T10:55:27Z

The USR2_DCDIN bit is tested for in register usr1. As the name suggests the usr2 register should be used instead. This fixes reading the Carrier detect status. Signed-off-by: Sascha Hauer Fixes: 90ebc4838666 ("serial: imx: repair and complete handshaking") Acked-by: Uwe Kleine-König Cc: # 4.5+ Reviewed-by: Fabio Estevam Signed-off-by: Greg Kroah-Hartman

serial: imx: Replace dmaengine old API

2016-09-15T10:35:49Z

dmaengine_terminate_all() is deprecated and should be replaced by dmaengine_terminate_sync() in non-atomic context or dmaengine_terminate_async() with dmaengine_synchronize(). See commit b36f09c3c441 ("dmaengine: Add transfer termination synchronization support") Signed-off-by: Fabien Lahoudere Signed-off-by: Greg Kroah-Hartman

serial: imx: add error messages when .probe fails

2016-09-13T16:54:34Z

Some functions called by serial_imx_probe emit an error message themself (like kmalloc() and friends). clk_prepare_enable() and devm_request_irq() however don't which might make the driver silently fail to probe. So add an error message for these. Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

Allowing UART DMA to be configured on i.MX53

2016-09-02T13:03:35Z

The UART DMA was only being configured on i.MX6Q compatible devices. We know that the DMA also works for i.MX53 devices, so enable uart DMA for imx53 and let the device tree to configure if DMA should be used or not. Signed-off-by: Martyn Welch Signed-off-by: Fabien Lahoudere Signed-off-by: Greg Kroah-Hartman

tty: serial: constify uart_ops structures

2016-09-02T13:01:16Z

Check for uart_ops structures that are only stored in the ops field of a uart_port structure. This field is declared const, so uart_ops structures that have this property can be declared as const also. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // @r disable optional_qualifier@ identifier i; position p; @@ static struct uart_ops i@p = { ... }; @ok@ identifier r.i; struct uart_port e; position p; @@ e.ops = &i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; struct uart_ops e; @@ e@i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct uart_ops i = { ... }; // Signed-off-by: Julia Lawall Signed-off-by: Greg Kroah-Hartman

serial: imx-serial - update RX error counters when DMA is used

2016-08-31T14:27:28Z

Update error counters when DMA is used for receiving data. Do this by using DMA transaction error event instead error interrupts to reduce interrupt load. Tested-by: Peter Senna Tschudin Acked-by: Peter Senna Tschudin Signed-off-by: Nandor Han Signed-off-by: Greg Kroah-Hartman

serial: imx-serial - update UART IMX driver to use cyclic DMA

2016-08-31T14:27:28Z

The IMX UART has a 32 bytes HW buffer which can be filled up in 2777us at 115200 baud or 80us at 4Mbaud (supported by IMX53). Taking this in consideration there is a good probability to lose data because of the DMA startup latency. Our tests (explained below) indicates a latency up to 4400us when creating interrupt load and ~70us without. When creating interrupt load I was able to see continuous overrun errors by checking serial driver statistics using the command: `cat /proc/tty/driver/IMX-uart`. Replace manual restart of DMA with cyclic DMA to eliminate data loss due to DMA engine startup latency (similar approch to atmel_serial.c driver). As result the DMA engine will start on the first serial data transfer and stops only when serial port is closed. Tests environment: Using the m53evk board I have used a GPIO for profiling the IMX serial driver. - The RX line and GPIO were connected to oscilloscope. - Run a small test program on the m53evk board that will only open and read data from ttymxc2 port. - Connect the ttymxc2 port to my laptop using a USB serial converter where another test program is running, able to send configurable packet lengths and intervals. - Serial ports configured at 115200 8N1. - Interrupts load created by disconnecting/connecting (3s interval) a USB hub, using a digital switch, with 4 USB devices (USB-Serial converter, USB SD card, etc) connected. (around 160 interrupts/second generated) - The GPIO was toggled HI in the `imx_int` when USR1_RRDY or USR1_AGTIM events are received and toggled back, once the DMA configuration is finalized, at the end of `imx_dma_rxint`. Measurements: The measurements were done from the end of the last byte (RX line) until the GPIO was toggled back LOW. Note: The GPIO toggling was done using `gpiod_set_value` method. Tests performed: 1. Sending 9 bytes packets at 8ms interval. Having the 9 bytes packets will activate the RRDY threshold event and IMX serial interrupt called. Results: - DMA start latency (interrupt start latency + DMA configuration) consistently 70us when system not loaded. - DMA start latency up to 4400us when system loaded. 2. Sending 40 bytes packet at 8mS interval. Results with load: - Able to observe overruns by running: `watch -n1 cat /proc/tty/driver/IMX-uart` Tested-by: Peter Senna Tschudin Acked-by: Peter Senna Tschudin Signed-off-by: Nandor Han Signed-off-by: Greg Kroah-Hartman