UART core function uart_update_mctrl relies on a cached value of
modem control lines. This was used but not updated by local RTS
control functions within imx.c. These are used for RS485 line
driver enable signalling. Having an out-of-date value in the cached
mctrl can result in the transmitter being enabled when it shouldn't
be.

Fix this by updating the mctrl value before applying it.
Signed-off-by: NIan Jamison <ian.dev@arkver.com>
Origin: id:8195c96e674517b82a6ff7fe914c7ba0f86e702b.1505375165.git.ian.dev@arkver.com
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This adds support for the rs485 specific properties defined in
Documentation/devicetree/bindings/serial/rs485.txt.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Forwarded: id:20170913081833.2740-7-u.kleine-koenig@pengutronix.de (v5)
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The i.MX driver defaulted to full duplex rs485 which is rather
unusual and doesn't match the default implemented in other drivers.

So change the default to half duplex.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The imx_transmit_buffer function should return if TX DMA has already
been started and not just skip over the buffer PIO write loop. (Which
did fix the initial problem, but could have unintentional side-effects)

Tested on an i.MX6Q board with half-duplex RS-485 and with RS-232.

Cc: Clemens Gruber <clemens.gruber@pqgruber.com>
Cc: Uwe-Kleine König <u.kleine-koenig@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Fixes: 514ab34d ("serial: imx: Prevent TX buffer PIO write when a DMA has been started")
Signed-off-by: NIan Jamison <ian.dev@arkver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If any key on console is pressed when board is suspended,
board hangs.

Driver's interrupt handler must be guaranteed not to run while
resume/suspend_noirq() are being executed. See include/linux/pm.h
for details.

Tested on i.MX6 based board.

The idea of this fix is based on commit in official i.MX kernel tree:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git
commit 81e8e7d91d81 ("tty: serial: imx: disable irq after suspend")

Disable rx irq after suspend to avoid interrupt coming in early resume.
Signed-off-by: NFugang Duan <B38611@freescale.com>
Signed-off-by: NMaxim Yu. Osipov <mosipov@ilbers.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The wait queue was only initialized and then checked if it contains
active jobs but a job is never added. The last real user was removed
with commit 9d297239 ("serial: imx-serial - update UART IMX driver
to use cyclic DMA").

Further there is no need to release the lock for the check if the port
should be woken up, (and IMHO there never was) so drop the unlock/lock
pair in dma_tx_callback(), too.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Function imx_transmit_buffer starts a TX DMA if DMA is enabled, since
commit 91a1a909 ("serial: imx: Support sw flow control in DMA mode").
It also carries on and attempts to write the same TX buffer using PIO.
This results in TX data corruption and double-incrementing xmit->tail
with the knock-on effect of tail passing head and a page of garbage
being sent out.

This seems to be triggered mostly when using RS485 half duplex on SMP
systems, but is probably not limited to just those.

Tested locally on an i.MX6Q with an RS485 half duplex transceiver on
UART3, and also by Clemens Gruber.
Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: NIan Jamison <ian.dev@arkver.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit a3015aff as there
are complaints that it is incorrect.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Nandor Han <nandor.han@ge.com>
Cc: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

The size of the DMA buffer can affect the delta time between data being
produced and data being consumed. Basically the DMA system will move
data to tty buffer when a) DMA buffer is full b) serial line is idle.
The situation is visible when producer generates data continuously and
there is no possibility for idle line. At this point the DMA buffer is
directly affecting the delta time.

The patch will add the possibility to configure the DMA buffers in DT,
which case by case can be configured separately for every driver
instance. The DT configuration is optional and in case missing the
driver will use the 4096 buffer with 4 periods (as before), therefore no
clients are impacted by this change.
Signed-off-by: NNandor Han <nandor.han@ge.com>
Signed-off-by: NRomain Perier <romain.perier@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, this IRQ is always enabled. Some devices might mux these pins
to other I/Os, like I2C. This could lead to spurious interrupts.

This commit makes this IRQ optional, by using the field have_rtscts.
Signed-off-by: NNandor Han <nandor.han@ge.com>
Signed-off-by: NRomain Perier <romain.perier@collabora.com>
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

IRDA support is gone since commit afe9cbb1 ("serial: imx: drop
support for IRDA"), so remove the remaining irda members from
imx_port structure.

While at it, also remove 'trcv_delay' which is also unused.
Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit e61c38d8 ("serial: imx: setup DCEDTE early and ensure DCD and
RI irqs to be off") has a flaw: While UCR3 and UFCR were modified using
read-modify-write before it switched to write register values
independent of the previous state. That's a good idea in principle (and
that's why I did it) but needs more care.

This patch reinstates read-modify-write for UFCR and for UCR3 ensures
that RXDMUXSEL and ADNIMP are set for post imx1.

Fixes: e61c38d8 ("serial: imx: setup DCEDTE early and ensure DCD and RI irqs to be off")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NMika Penttilä <mika.penttila@nextfour.com>
Tested-by: NMika Penttilä <mika.penttila@nextfour.com>
Acked-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Tested-by: NSteve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

18a42088 introduced a change to reduce the RX DMA latency on the first reception
when the serial port was opened for reading. However it was claiming a hardirq
unsafe lock after a hardirq safe lock which is not allowed and causes lockdep
to complain verbosely.

This patch changes the code to always start RX DMA earlier, instead of
relying on the flags used to open the serial port removing the code that
was looking for the serial file flags.
Signed-off-by: NPeter Senna Tschudin <peter.senna@collabora.com>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reduce RX DMA start latency for the first reception when port is opened
for reading. Instead of waiting for an interrupt signaling data on RX
FIFO or data too old on RX FIFO, start RX DMA immediately when the
serial port is opened for reading.

Before this patch, the average RX DMA latency for the first reception
was 42489 microseconds with a standard deviation of 25721 microseconds
in 36 samples.

After the patch the average RX DMA latency for the first reception, when
the serial port is opened for reading, is 653 microseconds with a
standard deviation of 294 microseconds in 36 samples.
Signed-off-by: NPeter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the UART is operated in DTE mode and UCR3_DCD or UCR3_RI are 1 (which
is the reset default) and the opposite side pulls the respective line to
its active level the irq triggers after it is requested in .probe.

These irqs were already disabled in .startup but this might be too late.

Also setup of the UFCR_DCEDTE bit (currently done in .set_termios) is
done very late which is critical as it also controls direction of some
pins.

So setup UFCR_DCEDTE earlier (in .probe) and also disable the broken
irqs in DTE mode there before requesting irqs.
Acked-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NFabio Estevam <fabio.estevam@nxp.com>
Tested-by: NClemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NSascha Hauer <s.hauer@pengutronix.de>
Fixes: 90ebc483 ("serial: imx: repair and complete handshaking")
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: <stable@vger.kernel.org> # 4.5+
Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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 b36f09c3 ("dmaengine: Add transfer termination synchronization support")
Signed-off-by: NFabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NMartyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: NFabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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/)

// <smpl>
@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 = { ... };
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NPeter Senna Tschudin <peter.senna@collabora.com>
Acked-by: NPeter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: NNandor Han <nandor.han@ge.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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: NPeter Senna Tschudin <peter.senna@collabora.com>
Acked-by: NPeter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: NNandor Han <nandor.han@ge.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Convert the Freescale IMX UART driver from using the vendor-specific
"fsl,uart-has-rtscts" to the generic "uart-has-rtscts" DT property, as
documented by the Generic Serial DT Bindings.

The old vendor-specific property is still recognized by the driver for
backwards compatibility, but deprecated.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable reporting of DSR events (which is named DTR in the registers
because Freescale uses the names as seem from a DCE).
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

According to tty_ioctl(4) (from man-pages 4.04) the rng member only
counts 0->1 transitions. For the other signals (DSR, CD, CTS) both edges
are supposed to be counted.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure that events that are not handled in the irq function don't
trigger an interrupt.

When the serial port is operated in DTE mode, the events for DCD and RI
events are enabled after a system reset by default.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This gives the irq core a chance to disable the serial interrupt in case
an event isn't cleared in the handler.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When in DTE mode, the bit USR2_RIIN is active low. So invert the logic
accordingly.

Fixes: 90ebc483 ("serial: imx: repair and complete handshaking")
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some RS-232 to RS-485 transceivers require Rx to be disabled on Tx to
avoid echo of Tx data into the Rx buffer. Specifically, the XR3160E
RS-232/RS-485/RS-422 transceiver behaves this way.

This commit disables Rx on active Tx when SER_RS485_ENABLED is active and
SER_RS485_RX_DURING_TX is disabled.

Note that this is a change in behavior of the driver. Until now
SER_RS485_RX_DURING_TX was enabled unconditionally even when disabled in
the TIOCSRS485 ioctl serial_rs485 flags field.

Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a non console i.MX UART is enabled in the device tree,
system suspend fails due to an unprepared clock:

[  638.794563] PM: Syncing filesystems ... done.
[  638.878902] Freezing user space processes ... (elapsed 0.002 seconds) done.
[  638.888454] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  638.996697] PM: suspend of devices complete after 97.200 msecs
[  639.002611] PM: suspend devices took 0.100 seconds
[  639.013020] PM: late suspend of devices complete after 2.288 msecs
[  639.021486] ------------[ cut here ]------------
[  639.026147] WARNING: CPU: 0 PID: 488 at drivers/clk/clk.c:732 clk_core_enable+0xc0/0x12c()
[  639.034413] Modules linked in:
[  639.037490] CPU: 0 PID: 488 Comm: system_server Tainted: G        W       4.4.0-rc5-pknbsp-svn2214-atag-v4.4-rc5-121-gebfd9cb #1304
[  639.049312] Hardware name: Freescale i.MX53 (Device Tree Support)
[  639.055444] [<c0016d54>] (unwind_backtrace) from [<c00140f8>] (show_stack+0x20/0x24)
[  639.063199] [<c00140f8>] (show_stack) from [<c02c99a0>] (dump_stack+0x20/0x28)
[  639.070442] [<c02c99a0>] (dump_stack) from [<c0024ca8>] (warn_slowpath_common+0x88/0xc0)
[  639.078541] [<c0024ca8>] (warn_slowpath_common) from [<c0024d0c>] (warn_slowpath_null+0x2c/0x34)
[  639.087332] [<c0024d0c>] (warn_slowpath_null) from [<c05171e8>] (clk_core_enable+0xc0/0x12c)
[  639.095777] [<c05171e8>] (clk_core_enable) from [<c05172f8>] (clk_enable+0x2c/0x40)
[  639.103441] [<c05172f8>] (clk_enable) from [<c0349880>] (imx_serial_port_suspend_noirq+0x20/0xe0)
[  639.112336] [<c0349880>] (imx_serial_port_suspend_noirq) from [<c03a26a0>] (dpm_run_callback+0x68/0x16c)
[  639.121825] [<c03a26a0>] (dpm_run_callback) from [<c03a2898>] (__device_suspend_noirq+0xf4/0x22c)
[  639.130705] [<c03a2898>] (__device_suspend_noirq) from [<c03a4b0c>] (dpm_suspend_noirq+0x148/0x30c)
[  639.139764] [<c03a4b0c>] (dpm_suspend_noirq) from [<c00511d4>] (suspend_devices_and_enter+0x2e8/0x6a4)
[  639.149078] [<c00511d4>] (suspend_devices_and_enter) from [<c00518a0>] (pm_suspend+0x310/0x4b8)
[  639.157782] [<c00518a0>] (pm_suspend) from [<c00500ec>] (state_store+0x7c/0xcc)
[  639.165099] [<c00500ec>] (state_store) from [<c02cb6dc>] (kobj_attr_store+0x1c/0x28)
[  639.172858] [<c02cb6dc>] (kobj_attr_store) from [<c01633d4>] (sysfs_kf_write+0x54/0x58)
[  639.180871] [<c01633d4>] (sysfs_kf_write) from [<c01629b4>] (kernfs_fop_write+0x100/0x1c8)
[  639.189152] [<c01629b4>] (kernfs_fop_write) from [<c00fb8b8>] (__vfs_write+0x3c/0xe8)
[  639.196991] [<c00fb8b8>] (__vfs_write) from [<c00fc810>] (vfs_write+0xa4/0x160)
[  639.204307] [<c00fc810>] (vfs_write) from [<c00fcac4>] (SyS_write+0x4c/0x98)
[  639.211363] [<c00fcac4>] (SyS_write) from [<c0010760>] (ret_fast_syscall+0x0/0x3c)

This does not happen for the common case of a single UART used as a console
(since imx_console_setup() already does a prepare)
Signed-off-by: NMartin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that imx_mctrl_check is implemented below imx_get_mctrl the former
can call the latter directly instead of via sport->port.ops->get_mctrl.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The .get_mctrl callback should not report the status of RTS or LOOP, so
drop this. Instead implement reporting the state of CAR (aka DCD) and
RI.

For .set_mctrl implement setting the DTR line.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

of_match_device could return NULL, and so cause a NULL pointer
dereference later.
Even if the probability of this case is very low, fixing it made
static analyzers happy.
Solving this with of_device_get_match_data made also code simplier.
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 9e7b399d.

Commit ("9e7b399d") causes the following warning and sometimes
also hangs the system:

------------[ cut here ]------------
 WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:868 mutex_trylock+0x20c/0x22c()
 DEBUG_LOCKS_WARN_ON(in_interrupt())
 Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-next-20150818-00001-g14418a6 #4
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<80012f08>] (dump_backtrace) from [<800130a4>] (show_stack+0x18/0x1c)
r6:00000364 r5:00000000 r4:00000000 r3:00000000
[<8001308c>] (show_stack) from [<807902b8>] (dump_stack+0x88/0xa4)
[<80790230>] (dump_stack) from [<8002a604>] (warn_slowpath_common+0x80/0xbc)
r5:807945c4 r4:80ab3b50
[<8002a584>] (warn_slowpath_common) from [<8002a6e4>] (warn_slowpath_fmt+0x38/0x40)
r8:00000000 r7:8131100c r6:8054c3cc r5:8131300c r4:80b0a570
[<8002a6b0>] (warn_slowpath_fmt) from [<807945c4>] (mutex_trylock+0x20c/0x22c)
r3:8095d0d8 r2:8095ab28
[<807943b8>] (mutex_trylock) from [<8054c3cc>] (clk_prepare_lock+0x14/0xf4)
r7:8131100c r6:be3f0c80 r5:00000037 r4:be3f0c80
[<8054c3b8>] (clk_prepare_lock) from [<8054dbfc>] (clk_prepare+0x18/0x30)
r5:00000037 r4:be3f0c80
[<8054dbe4>] (clk_prepare) from [<8036a600>] (imx_console_write+0x30/0x244)
r4:812d0bc8 r3:8132b9a4

To reproduce the problem we only need to let the board idle for something
like 30 seconds.

Tested on a imx6q-sabresd.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: NEduardo Valentin <edubezval@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The RX bytecount was only updated in the PIO path and thus
the device erroneously reported a value of 0 if DMA is in
use.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NJiada Wang <jiada_wang@mentor.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>