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: Fugang Duan <B38611@freescale.com>
Signed-off-by: Maxim Yu. Osipov <mosipov@ilbers.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Ian Jamison <ian.dev@arkver.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit a3015aff as there
are complaints that it is incorrect.

Reported-by: Uwe 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: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Signed-off-by: Greg 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: Nandor Han <nandor.han@ge.com>
Signed-off-by: Romain Perier <romain.perier@collabora.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg 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: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Mika Penttilä <mika.penttila@nextfour.com>
Tested-by: Mika Penttilä <mika.penttila@nextfour.com>
Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
Tested-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Greg 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: Peter Senna Tschudin <peter.senna@collabora.com>
Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Greg 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: Peter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: Greg 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: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg 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: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg 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: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Signed-off-by: Greg 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: Sascha Hauer <s.hauer@pengutronix.de>
Fixes: 90ebc483 ("serial: imx: repair and complete handshaking")
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: <stable@vger.kernel.org> # 4.5+
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Greg 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: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Martyn Welch <martyn.welch@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>
Signed-off-by: Greg 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: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Greg 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: Peter Senna Tschudin <peter.senna@collabora.com>
Acked-by: Peter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Greg 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: Peter Senna Tschudin <peter.senna@collabora.com>
Acked-by: Peter Senna Tschudin <peter.senna@collabora.com>
Signed-off-by: Nandor Han <nandor.han@ge.com>
Signed-off-by: Greg 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: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Greg 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: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: LABBE Corentin <clabbe.montjoie@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Greg 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: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit enabling DMA support even if no flow control is present
was reverted on the grounds that it uncovered a number of bugs in
the code that lead to hanging tty devices and/or missing characters.

After tracking down the issues it is clear that those were generic
bugs and had nothing to do with flow control being present or not,
only that allowing DMA without hardware flow control increased
the exposure of that code a lot.

Now that those bugs are fixed, it should be safe to re-enable DMA
support.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The reference manual states that idle condition detect should not be used
with DMA transfers, as the ROM SDMA scripts don't check those conditions.

The RAM SDMA scripts worked around this, but the change broke compatibility
with the ROM scripts.

The previous commits fixed the DMA burst sizes, so that the aging timer is
now working as described in the reference manual. With this fixed we can
remove the hack of using the idle condition detect to stop the DMA transfer
if there are no new characters incoming.

This should work with both the ROM and RAM SDMA scripts.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Triggering the DMA engine for every byte is horribly inefficient.
Also it doesn't allow to use the aging timer for the RX FIFO as this
requires the DMA engine to leave one byte remaining in the FIFO when
doing a normal burst transfer.

Adjust watermark levels so that the DMA engine can do at least 8 byte
burst transfers. This is a conservative value, as the both TX and RX
FIFOs are able to contain 32 bytes.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Simplify the DMA restart logic to always queue up the next transfer
immediately if there is at least one more byte available in the FIFO,
so that the transfer will finish in a limited time.

This way the driver stops to rely on zero length transfers to signal
transfers ends. Those will go away when the idle detect DMA requests
are disabled.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Jiada Wang <jiada_wang@mentor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>