I changed the prototype of the function earlier but only
in the section for CONFIG_DMA_ENGINE, not the alternative.
This makes the driver build again, e.g. for vexpress_defconfig.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The latest r1p5-revision of the ARM PL011 UART has 32-byte FIFOs,
while all earlier ones have 16-byte FIFOs. This patch suggests
a way to set the FIFO-size correctly & flexibly by using a member
function named get_fifosize, rather than using the fifosize member
variable. The function takes the UARTPeriphID, and returns the
correct FIFO size.
Signed-off-by: NJongsung Kim <neidhard.kim@lge.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Following patch will fix build error if CONFIG_DMA_ENGINE is unset.
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NChanho Min <chanho.min@lge.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In DMA support, The received data is not pushed to tty until the DMA buffer
is filled. But some megabyte rate chips such as BT expect fast response and
data should be pushed immediately. In order to fix this issue, We suggest
the use of the timer for polling DMA buffer.
In our test, no data loss occurred at high-baudrate as compared with interrupt-
driven (We tested with 3Mbps).
We changes:

- We add timer for polling. If we set poll_timer to 10, every 10ms,
 timer handler checks the residue in the dma buffer and transfer data
 to the tty. Also, last_residue is updated for the next polling.

- poll_timeout is used to prevent the timer's system cost.
  If poll_timeout is set to 3000 and no data is received in 3 seconds,
  we inactivate poll timer and driver falls back to interrupt-driven.
  When data is received again in FIFO and UART irq is occurred, we switch
  back to DMA mode and start polling.

- We use consistent DMA mappings to avoid from the frequent cache operation
  of the timer function for default.

- pl011_dma_rx_chars is modified. the pending size is recalculated because
  data can be taken by polling.

- the polling time is adjusted if dma rx poll is enabled but no rate is
  specified. Ideal polling interval to push 1 character at every interval
  is the reciprocal of 'baud rate / 10 line bits per character / 1000 ms
  per sec'. But It is very aggressive to system. Experimentally,
 '10000000 / baud' is suitable to receive dozens of characters. the poll rate
 can be specified statically by dma_rx_poll_rate of the platform data as well.

Changes compared to v1:
 - Use of consistent DMA mappings.
 - Added dma_rx_poll_rate in platform data to specify the polling interval.
 - Added dma_rx_poll_timeout in platform data to specify the polling timeout.

Changes compared to v2:
 - Use of consistent DMA mappings for default.
 - Added dma_rx_poll_enable in platform data to adjust the polling time
   according to the baud rate.
 - remove unnecessary lock from the polling function.
Signed-off-by: NChanho Min <chanho.min@lge.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.

This also adds a binding document specific to the pl011 controller,
and extends the generic primecell binding to mention "dmas" and other
common properties.

Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-arm-kernel@lists.infradead.org

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

Now, the one where most of tty_port_tty_get gets removed:
tty_flip_buffer_push.

IOW we also closed all the races in drivers not using tty_port_tty_get
at all yet.

Also we move tty_flip_buffer_push declaration from include/linux/tty.h
to include/linux/tty_flip.h to all others while we are changing it
anyway.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

tty_insert_flip_string this time.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This switches a bunch of allocation and remapping to use the
devm_* garbage collected methods and cleans up the error
path and remove() paths consequently.

devm_ioremap() is only in <linux/io.h> so fix up the
erroneous <asm/*> include as well.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NDomenico Andreoli <domenico.andreoli@linux.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to quiesce interrupts in the poll_get_char routine, otherwise,
if used with KGDB NMI debugger, we'll keep reentering the NMI.

Quiescing interrupts is pretty straightforward, except for TXIM
interrupt. The interrupt has "ready to transmit" meaning, so it's
almost always raised, and the only way to silence it is to mask it. But
that's OK, ops->start_tx will unmask it.
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The callback is used to initialize the hardware, nothing else should be
done, i.e. we should not request interrupts (but we can and do unmask
some of them, as they might be useful for NMI entry).

As a side-effect, the patch also fixes a division by zero[1] when booting
with kgdboc options specified (e.g. kgdboc=ttyAMA0,115200n8). The issue
happens because serial core calls set_termios callback, but the driver
doesn't know clock frequency, and thus cannot calculate proper baud rate
values.

[1]
WARNING: at drivers/tty/serial/serial_core.c:400 uart_get_baud_rate+0xe8/0x14c()
Modules linked in:
[<c0018e50>] (unwind_backtrace+0x0/0xf0) from [<c0020ae8>] (warn_slowpath_common+0x4c/0x64)
[<c0020ae8>] (warn_slowpath_common+0x4c/0x64) from [<c0020b1c>] (warn_slowpath_null+0x1c/0x24)
[<c0020b1c>] (warn_slowpath_null+0x1c/0x24) from [<c0185ed8>] (uart_get_baud_rate+0xe8/0x14c)
[<c0185ed8>] (uart_get_baud_rate+0xe8/0x14c) from [<c0187078>] (pl011_set_termios+0x48/0x278)
[<c0187078>] (pl011_set_termios+0x48/0x278) from [<c01850b0>] (uart_set_options+0xe8/0x114)
[<c01850b0>] (uart_set_options+0xe8/0x114) from [<c0185de4>] (uart_poll_init+0xd4/0xe0)
[<c0185de4>] (uart_poll_init+0xd4/0xe0) from [<c016da8c>] (tty_find_polling_driver+0x100/0x17c)
[<c016da8c>] (tty_find_polling_driver+0x100/0x17c) from [<c0188538>] (configure_kgdboc+0xc8/0x1b8)
[<c0188538>] (configure_kgdboc+0xc8/0x1b8) from [<c00088a4>] (do_one_initcall+0x30/0x168)
[<c00088a4>] (do_one_initcall+0x30/0x168) from [<c033784c>] (do_basic_setup+0x94/0xc8)
[<c033784c>] (do_basic_setup+0x94/0xc8) from [<c03378e0>] (kernel_init+0x60/0xf4)
[<c03378e0>] (kernel_init+0x60/0xf4) from [<c00144a0>] (kernel_thread_exit+0x0/0x8)
---[ end trace 7d41c9186f342c40 ]---
Division by zero in kernel.
[<c0018e50>] (unwind_backtrace+0x0/0xf0) from [<c014546c>] (Ldiv0+0x8/0x10)
[<c014546c>] (Ldiv0+0x8/0x10) from [<c0187098>] (pl011_set_termios+0x68/0x278)
[<c0187098>] (pl011_set_termios+0x68/0x278) from [<c01850b0>] (uart_set_options+0xe8/0x114)
[<c01850b0>] (uart_set_options+0xe8/0x114) from [<c0185de4>] (uart_poll_init+0xd4/0xe0)
[<c0185de4>] (uart_poll_init+0xd4/0xe0) from [<c016da8c>] (tty_find_polling_driver+0x100/0x17c)
[<c016da8c>] (tty_find_polling_driver+0x100/0x17c) from [<c0188538>] (configure_kgdboc+0xc8/0x1b8)
[<c0188538>] (configure_kgdboc+0xc8/0x1b8) from [<c00088a4>] (do_one_initcall+0x30/0x168)
[<c00088a4>] (do_one_initcall+0x30/0x168) from [<c033784c>] (do_basic_setup+0x94/0xc8)
[<c033784c>] (do_basic_setup+0x94/0xc8) from [<c03378e0>] (kernel_init+0x60/0xf4)
[<c03378e0>] (kernel_init+0x60/0xf4) from [<c00144a0>] (kernel_thread_exit+0x0/0x8)
Division by zero in kernel.
[<c0018e50>] (unwind_backtrace+0x0/0xf0) from [<c014546c>] (Ldiv0+0x8/0x10)
[<c014546c>] (Ldiv0+0x8/0x10) from [<c0183a98>] (uart_update_timeout+0x4c/0x5c)
[<c0183a98>] (uart_update_timeout+0x4c/0x5c) from [<c01870f8>] (pl011_set_termios+0xc8/0x278)
[<c01870f8>] (pl011_set_termios+0xc8/0x278) from [<c01850b0>] (uart_set_options+0xe8/0x114)
[<c01850b0>] (uart_set_options+0xe8/0x114) from [<c0185de4>] (uart_poll_init+0xd4/0xe0)
[<c0185de4>] (uart_poll_init+0xd4/0xe0) from [<c016da8c>] (tty_find_polling_driver+0x100/0x17c)
[<c016da8c>] (tty_find_polling_driver+0x100/0x17c) from [<c0188538>] (configure_kgdboc+0xc8/0x1b8)
[<c0188538>] (configure_kgdboc+0xc8/0x1b8) from [<c00088a4>] (do_one_initcall+0x30/0x168)
[<c00088a4>] (do_one_initcall+0x30/0x168) from [<c033784c>] (do_basic_setup+0x94/0xc8)
[<c033784c>] (do_basic_setup+0x94/0xc8) from [<c03378e0>] (kernel_init+0x60/0xf4)
[<c03378e0>] (kernel_init+0x60/0xf4) from [<c00144a0>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This works around a few glitches in the ST version of the PL011
serial driver when using very high baud rates, as we do in the
Ux500: 3, 3.25, 4 and 4.05 Mbps.

Problem Observed/rootcause:

When using high baud-rates, and the baudrate*8 is getting close to
the provided clock frequency (so a division factor close to 1), when
using bursts of characters (so they are abutted), then it seems as if
there is not enough time to detect the beginning of the start-bit which
is a timing reference for the entire character, and thus the sampling
moment of character bits is moving towards the end of each bit, instead
of the middle.

Fix:
Increase slightly the RX baud rate of the UART above the theoretical
baudrate by 5%. This will definitely give more margin time to the
UART_RX to correctly sample the data at the middle of the bit period.

Also fix the ages old copy-paste error in the very stressed comment,
it's referencing the registers used in the PL010 driver rather than
the PL011 ones.
Signed-off-by: NGuillaume Jaunet <guillaume.jaunet@stericsson.com>
Signed-off-by: NChristophe Arnal <christophe.arnal@stericsson.com>
Signed-off-by: NMatthias Locher <matthias.locher@stericsson.com>
Signed-off-by: NRajanikanth HV <rajanikanth.hv@stericsson.com>
Cc: stable <stable@vger.kernel.org>
Cc: Bibek Basu <bibek.basu@stericsson.com>
Cc: Par-Gunnar Hjalmdahl <par-gunnar.hjalmdahl@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bug flag .interrupt_may_hang is not used since commit
4fd0690b
"serial: pl011: implement workaround for CTS clear event issue"
so delete it.

Cc: Rajanikanth H.V <rajanikanth.hv@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the order of UART nodes is changed in the device tree, then tty dev
devices are attached to different serial ports causing the console to
be directed to a different physical serial port. The "serial" aliases
in the device tree should prevent this.

This patch ensures that the UART driver creates tty devices that
honour these aliases if a device tree is present.
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NMatthew Leach <matthew.leach@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clk_prepare_enable and clk_disable_unprepare combine clk_prepare and
clk_enable, and clk_disable and clk_unprepare.  The9 make the code more
concise, and ensure that clk_unprepare is called when clk_enable fails.

A simplified version of the semantic patch that introduces calls to these
functions is as follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e;
@@

- clk_prepare(e);
- clk_enable(e);
+ clk_prepare_enable(e);

@@
expression e;
@@

- clk_disable(e);
- clk_unprepare(e);
+ clk_disable_unprepare(e);
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NAlessandro Rubini <rubini@gnudd.com>
Acked-by: NGiancarlo Asnaghi <giancarlo.asnaghi@st.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The PL011 driver has a number of symbols referring to "pl01x"
(probably once shared with the pl010 driver) and some even named
"pl010" (probably a pure copy-paste artifact). Lets name all
local static functions with the prefix pl011_* for clarity.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We had a boot regression in Ux500 in the merge window because
two orthogonal pin control schemes for the PL011 were merged
at the same time:

- One using the .init() and .exit() hooks into the platform
  for Ux500 putting the pins into default vs sleep state
  respectively as the port was started/stopped.
  commit a0980660
  "ARM: ux500: switch to using pinctrl for uart0"

- One hogging the default setting at PL011 probe()
  commit 258e0551
  "serial: amba-pl011: adopt pinctrl support"

To get a solution that works for both let's scrap the stuff
in the platform callbacks, instead have the driver itself
select default and sleep states when the port is
started/stopped. Hopefully this works for all clients.
Platform callbacks are bad for device tree migration anyway,
so this rids us of another problem in Ux500.

Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Reported-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Cc: linux-serial@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Problem Observed:
- interrupt status is set by rising or falling edge on CTS line
- interrupt status is cleared on a .0. to .1. transition of the
  interrupt-clear register bit 1.
- interrupt-clear register is reset by hardware once the interrupt
  status is .0..
  Remark: It seems not possible to read this register back by the
  CPU though, but internally this register exists.
- when simultaneous set and reset event on the interrupt status
  happens, then the set-event has priority and the status remains
  .1.. As a result the interrupt-clear register is not reset to
  .0., and no new .0. to .1. transition can be detected on it when
  writing a .1. to it.
  This implies race condition, the clear must be performed at least
  one UARTCLK the riding edge of CTS RIS interrupt.

Fix:
  Instead of resetting UART as done in commit
  c16d51a3
  "amba pl011: workaround for uart registers lockup" do the
  following:

  write .0. and then  .1. to the interrupt-clear register to make
  sure that this transition is detected. According to the datasheet
  writing a .0. does not have any effect, but actually it allows to
  reset the internal interrupt-clear register.

  Take into account:
  The .0. needs to last at least for one clk_uart clock period
  (~ 38 MHz, 26.08ns)

This way we can do away with the tasklet and keep only a tiny
fix triggered by the variant flag introduced in this patch.
Signed-off-by: NGuillaume Jaunet <guillaume.jaunet@stericsson.com>
Signed-off-by: NChristophe Arnal <christophe.arnal@stericsson.com>
Signed-off-by: NMatthias Locher  <Matthias.Locher@stericsson.com>
Signed-off-by: NRajanikanth H.V <rajanikanth.hv@stericsson.com>
Reviewed-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 360f748b204275229f8398cb2f9f53955db1503b
"serial: PL011: clear pending interrupts"
attempts to clear interrupts by writing to a
yet-unassigned memory address. This fixes the issue.

The breaking patch is marked for stable so should be
carried along with the other patch.

Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: stable <stable@vger.kernel.org>
Cc: Nicolas Pitre <nico@fluxnic.net>
Reported-by: NViresh Kumar <viresh.kumar@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add inline wrappers for device_prep_slave_sg() and device_prep_dma_cyclic()
interfaces to hide new parameter from current users of affected interfaces.
Convert current users to use new wrappers instead of direct calls.
Suggested by Russell King [https://lkml.org/lkml/2012/2/3/269].
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Chanho Min reported that when the boot loader transfers
control to the kernel, there may be pending interrupts
causing the UART to lock up in an eternal loop trying to
pick tokens from the FIFO (since the RX interrupt flag
indicates there are tokens) while in practice there are
no tokens - in fact there is only a pending IRQ flag.

This patch address the issue with a combination of two
patches suggested by Russell King that clears and mask
all interrupts at probe() and clears any pending error
and RX interrupts at port startup time.

We suspect the spurious interrupts are a side-effect of
switching the UART from FIFO to non-FIFO mode.

Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Reported-by: NChanho Min <chanho0207@gmail.com>
Suggested-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJong-Sung Kim <neidhard.kim@lge.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In DMA-operated uart, I found that rx data can be taken by the UART
interrupts during the DMA irq handler. pl011_int is occurred just
before it goes inside spin_lock_irq. When it returns to the callback,
DMA buffer already has been flushed. Then, pl011_dma_rx_chars gets
invalid data. So I add check for the residue as the patch bellow.
Signed-off-by: NChanho Min <chanho.min@lge.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

.device_fc is added in struct dma_slave_config recently. All user drivers, which
want DMA to be the flow controller must pass this field as false. As earlier
driver don't look to use this feature, mark it false for now.
Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.

Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.

The checks for sysrq and oops_in_progress are taken
from 8250.c.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Reviewed-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: NBibek Basu <bibek.basu@stericsson.com>
Reviewed-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

In present driver, shutdown clears RTS and DTR in CR register. But the
documentation "Documentation/serial/driver" suggests not to disable
RTS and DTR in shutdown(). Also RTS and DTR is preserved between shutdown
and startup calls, i.e. these are restored in startup if they were enabled
while doing shutdown. So that if RTS and DTR are set using pl011_set_mctrl
then it should continue even after shutdown->startup sequence.
For throttling/unthrottling user should call pl011_set_mctrl.
Signed-off-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NDave Martin <dave.martin@linaro.org>

fixup usage of dma direction by introducing dma_transfer_direction,
this patch moves spi, serial drivers to use new enum
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@iki.fi>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This workaround aims to break the deadlock situation
which raises during continuous transfer of data for long
duration over uart with hardware flow control. It is
observed that CTS interrupt cannot be cleared in uart
interrupt register (ICR). Hence further transfer over
uart gets blocked.

It is seen that during such deadlock condition ICR
don't get cleared even on multiple write. This leads
pass_counter to decrease and finally reach zero. This
can be taken as trigger point to run this UART_BT_WA.

Workaround backups the register configuration, does soft
reset of UART using BIT-0 of PRCC_K_SOFTRST_SET/CLEAR
registers and restores the registers.

This patch also provides support for uart init and exit
function calls if present.
Signed-off-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This workaround aims to break the deadlock situation
which raises during continuous transfer of data for long
duration over uart with hardware flow control. It is
observed that CTS interrupt cannot be cleared in uart
interrupt register (ICR). Hence further transfer over
uart gets blocked.

It is seen that during such deadlock condition ICR
don't get cleared even on multiple write. This leads
pass_counter to decrease and finally reach zero. This
can be taken as trigger point to run this UART_BT_WA.

Workaround backups the register configuration, does soft
reset of UART using BIT-0 of PRCC_K_SOFTRST_SET/CLEAR
registers and restores the registers.

This patch also provides support for uart init and exit
function calls if present.
Signed-off-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

remove invalid location line in each file header after location
moved from driver/char to driver/tty
Signed-off-by: NJovi Zhang <bookjovi@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>

This piece of code was just slightly different between the DMA
and IRQ paths, in DMA mode we surely shouldn't read more than
256 character either, so factor this out in its own function and
use for both DMA and PIO mode.

Tested on Ux500 and U300.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This adds an optional RX DMA codepath for the devices that
support this by using the apropriate burst sizes instead of
pulling single bytes.

Includes portions of code written by Russell King during
a PL08x hacking session.

This has been tested on U300 and Ux500.
Tested-by: NJerzy Kasenberg <jerzy.kasenberg@tieto.com>
Tested-by: NGrzegorz Sygieda <grzegorz.sygieda@tieto.com>
Tested-by: NMarcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: NPer Forlin <per.friden@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Make Primecell driver probe functions take a const pointer to their
ID tables.  Drivers should never modify their ID tables in their
probe handler.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The serial drivers are really just tty drivers, so move them to
drivers/tty/ to make things a bit neater overall.

This is part of the tty/serial driver movement proceedure as proposed by
Arnd Bergmann and approved by everyone involved a number of months ago.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Rogier Wolff <R.E.Wolff@bitwizard.nl>
Cc: Michael H. Warfield <mhw@wittsend.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

ST Micro variants has some specific dma burst threshold compensation,
which allows them to make better use of a DMA controller.  Add support
to set this up.

Based on a patch from Linus Walleij.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add DMA engine support for transmit to the PL011 driver.  Based on a
patch from Linus Walliej, with the following changes:

- remove RX DMA support.  As PL011 doesn't give us receive timeout
  interrupts, we only get notified of received data when the RX DMA
  has completed.  This rather sucks for interactive use of the TTY.

- remove abuse of completions.  Completions are supposed to be for
  events, not to tell what condition buffers are in.  Replace it with
  a simple 'queued' bool.

- fix locking - it is only safe to access the circular buffer with the
  port lock held.

- only map the DMA buffer when required - if we're ever behind an IOMMU
  this helps keep IOMMU usage down, and also ensures that we're legal
  when we change the scatterlist entry length.

- fix XON/XOFF sending - we must send XON/XOFF characters out as soon
  as possible - waiting for up to 4095 characters in the DMA buffer
  to be sent first is not acceptable.

- fix XON/XOFF receive handling - we need to stop DMA when instructed
  to by the TTY layer, and restart it again when instructed to.  There
  is a subtle problem here: we must not completely empty the circular
  buffer with DMA, otherwise we will not be notified of XON.

- change the 'enable_dma' flag into a 'using DMA' flag, and track
  whether we can use TX DMA by whether the channel pointer is non-NULL.
  This gives us more control over whether we use DMA in the driver.

- we don't need to have the TX DMA buffer continually allocated for
  each port - instead, allocate it when the port starts up, and free
  it when it's shut down.  Update the 'using DMA' flag if we get
  the buffer, and adjust the TTY FIFO size appropriately.

- if we're going to use PIO to send characters, use the existing IRQ
  based functionality rather than reimplementing it.  This also ensures
  we call uart_write_wakeup() at the appropriate time, otherwise we'll
  stall.

- use DMA engine helper functions for type safety.

- fix init when built as a module - we can't have to initcall functions,
  so we must settle on one.  This means we can eliminate the deferred
  DMA initialization.

- there is no need to terminate transfers on a failed prep_slave_sg()
  call - nothing has been setup, so nothing needs to be terminated.
  This avoids a potential deadlock in the DMA engine code
  (tasklet->callback->failed prepare->terminate->tasklet_disable
   which then ends up waiting for the tasklet to finish running.)

- Dan says that the submission callback should not return an error:
  | dma_submit_error() is something I should have removed after commit
  | a0587bcf "ioat1: move descriptor allocation from submit to prep" all
  | errors should be notified by prep failing to return a descriptor
  | handle.  Negative dma_cookie_t values are only returned by the
  | dma_async_memcpy* calls which translate a prep failure into -ENOMEM.
  So remove the error handling at that point.  This also solves the
  potential deadlock mentioned in the previous comment.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As the DMA support introduces a separate interrupt-time callback, our
interrupt handler will not be the only handler which takes the port
lock, so we need to ensure that IRQs are disabled.  We must use the
_irqsave variant so we don't inadvertently enable interrupts.
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>