Refactor base port operations into new file; 8250_port.c.

Legacy irq handling, RSA port support, port storage for universal
driver, driver definition, module parameters and linkage remain in
8250_core.c

The source file split and resulting modules is diagrammed below:

  8250_core.c ====>   8250_core.c __
              \                     \
               \                     +-- 8250.ko (alias 8250_core)
                \     8250_pnp.c  __/     (universal driver)
                 \
                  =>  8250_port.c __
                                    \
                                     +-- 8250_base.ko
                      8250_dma.c  __/     (port operations)
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

OMAP h/w-assisted IXON flow control is borked. The transmitter becomes
stuck if XON is never received; clearing the fifos or resetting the
rx flow control bits has no effect.

Remove auto-IXANY as well, since without auto-IXON, it has no purpose.
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Due to Advisory 21 as documented in AM437x errata document,
UART module cannot be disabled once DMA is used. The only
workaround is to softreset the module before disabling it.

DRA7x UARTs are compatible to AM437x UARTs in terms of
this errata and prescribed workaround.

Enable usage of workaround for this errata on DRA7x SoCs.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

AM335x, AM437x and DRA7x SoCs have an errata[1] due to which UART
cannot be idled after it has been used with DMA.

OMAP3 has a similar sounding errata which has been worked around
in a2fc3661 ("ARM: OMAP3: Use manual idle for UARTs
because of DMA errata"). But the workaround used there does not
apply to AM335x, AM437x SoCs.

After using DMA, the UART module on these SoCs must be soft reset
to go to idle.

This patch implements that errata workaround. It is expected that
UART will be used with DMA so no explicit check for DMA usage
has been added for errata applicability.

MDR1 register needs to be restored right after soft-reset because
"UART mode" must be set in that register for module wake-up on AM335x
to work. As a result, SCR register is now used to determine if
context was lost during sleep.

[1] See Advisory 21 in AM437x errata SPRZ408B, updated April 2015.
    http://www.ti.com/lit/er/sprz408b/sprz408b.pdfSigned-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use of of_machine_is_compatible() for handling AM335x specific
"DMA kick" quirk in 8250_omap driver makes it ugly to extend the
quirk for other platforms. Instead use a new compatible.

The new compatible will also make it easier to take care of
other quirks on AM335x and like SoCs.

In order to not break backward DTB compatibility for users of
8250_omap driver on AM335x based boards, existing use of
of_machine_is_compatible() has not been removed.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The silicon errata[1] workaround implemented in a follow-on
patch, "serial: 8250_omap: workaround errata on disabling
UART after using DMA", requires MDR1 register programming.

Extract MDR1 register update into helper function,
omap8250_update_mdr1() to help with that.

[1] Advisory 21 in http://www.ti.com/lit/er/sprz408b/sprz408b.pdfSigned-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

omap_device infrastructure has a suspend_noirq hook which
runtime suspends all devices late in the suspend cycle (see
_od_suspend_noirq() in arch/arm/mach-omap2/omap_device.c)

This leads to a NULL pointer exception in 8250_omap driver
since by the time omap8250_runtime_suspend() is called, 8250_dma
driver has already set rxchan to NULL via serial8250_release_dma().

Make an explicit check to see if rxchan is NULL in
runtime_{suspend|resume} hooks to fix this.
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fintek chip can be configured for io addresses different than the standard.

Query the chip for the configured addresses and try to match it with the
pnp address.
Reported-by: NPeter Hong <peter_hong@fintek.com.tw>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Chip can be configured to use entry key different than 0x77. Try all the
valid keys until one gives out the right chip id.
Reported-by: NPeter Hong <peter_hong@fintek.com.tw>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are some chips with the same interface but different chip ip.
Reported-by: NPeter Hong <peter_hong@fintek.com.tw>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fintek chip can be connected at address 0x4e and also 0x2e.
Add some logic to find out the address of the chip.
Reported-by: NPeter Hong <peter_hong@fintek.com.tw>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Save the port index and the line id in a private structure.
Reported-by: NPeter Hong <peter_hong@fintek.com.tw>
Reviewed-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Introduce a driver suitable for use with the UARTs present in
Ingenic SoCs such as the JZ4740 & JZ4780. These are described as being
ns16550 compatible but aren't quite - they require the setting of an
extra bit in the FCR register to enable the UART module. The serial_out
implementation is the same as that in arch/mips/jz4740/serial.c - which
will shortly be removed.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: linux-serial@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: John Crispin <blogic@openwrt.org>
Patchwork: https://patchwork.linux-mips.org/patch/10159/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The internal clock of the master chip, which is usually 125MHz, is only half
(62.5MHz) for the slave chips. So we have to adjust the uartclk for all the
slave ports. Therefor we add a new function to determine if a slave chip is
present and update pci_xr17v35x_setup accordingly.
Signed-off-by: NSoeren Grunewald <soeren.grunewald@desy.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
single 12 port chip. This works the same way as the combining two XR17V358
chips. But the reported device id then is 0x4358.
Signed-off-by: NSoeren Grunewald <soeren.grunewald@desy.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We can now use generic wakeirq handling and remove the custom handling
for the wake-up interrupts.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The currently in-use port->startup and port->shutdown are "okay". The
startup part for instance does the tiny omap extra part and invokes
serial8250_do_startup() for the remaining pieces. The workflow in
serial8250_do_startup() is okay except for the part where UART_RX is
read without a check if there is something to read. I tried to
workaround it in commit 0aa525d1 ("tty: serial: 8250_core: read only
RX if there is something in the FIFO") but then reverted it later in
commit ca8bb4ae ("serial: 8250: Revert "tty: serial: 8250_core: read
only RX if there is something in the FIFO"").

This is the second attempt to get it to work on older OMAPs without
breaking other chips this time
Peter Hurley suggested to pull in the few needed lines from
serial8250_do_startup() and drop everything else that is not required
including making it simpler like using just request_irq() instead the
chain handler like it is doing now.
So lets try that.

Fixes: ca8bb4ae ("serial: 8250: Revert "tty: serial: 8250_core:
       read only RX if there is something in the FIFO"")
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Serial port driver for the 8250-based UART found on LPC18xx/43xx
devices. The UART is 16550A compatible with additional features
like RS485 support, synchronous mode, IrDA, and DMA.

For now only basic UART and RS485 operation is supported.
Signed-off-by: NJoachim Eastwood <manabian@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add the driver for on-chip UART used on UniPhier SoCs.

This hardware is similar to 8250, but the register mapping is
slightly different:
  - The offset to FCR, MCR is different.
  - The divisor latch access bit does not exist.  Instead, the
    divisor latch register is available at offset 9.

This driver overrides serial_{in,out}, dl_{read,write} callbacks,
but wants to borrow most of code from 8250_core.c.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

On many new Intel SoCs the UART has an integrated DMA engine
(iDMA). In order to use it a special filter function is needed.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

serial8250_set_mctrl() is a void type function.  Returning something
does not look nice.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the mediatek serial port driver is built-in, but serial
console is disabled in Kconfig (e.g. when the serial driver
itself is a loadable module), we get this build error:

drivers/built-in.o: In function `early_mtk8250_setup':
undefined reference to `early_serial8250_setup'

To avoid that problem, this patch encloses the early_mtk8250_setup
function in #ifdef CONFIG_SERIAL_8250_CONSOLE, the same symbol
that guards the early_serial8250_setup function.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NEddie Huang <eddie.huang@mediatek.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The currently in-use port->startup and port->shutdown are "okay". The
startup part for instance does the tiny omap extra part and invokes
serial8250_do_startup() for the remaining pieces. The workflow in
serial8250_do_startup() is okay except for the part where UART_RX is
read without a check if there is something to read. I tried to
workaround it in commit 0aa525d1 ("tty: serial: 8250_core: read only
RX if there is something in the FIFO") but then reverted it later in
commit ca8bb4ae ("serial: 8250: Revert "tty: serial: 8250_core: read
only RX if there is something in the FIFO"").

This is the second attempt to get it to work on older OMAPs without
breaking other chips this time
Peter Hurley suggested to pull in the few needed lines from
serial8250_do_startup() and drop everything else that is not required
including making it simpler like using just request_irq() instead the
chain handler like it is doing now.
So lets try that.

Fixes: ca8bb4ae ("serial: 8250: Revert "tty: serial: 8250_core:
       read only RX if there is something in the FIFO"")
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The port.fifosize member has already been copied at 8 lines above.
Maybe the compiler optimization can clean it away, but just in case.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When nr_uarts was set to 0 (via config or 8250_core.nr_uarts), we crash
early on x86 because serial8250_isa_init_ports dereferences base_ops
which remains NULL. In fact, there is nothing to do for all the callers
of serial8250_isa_init_ports if there are no uarts.

Based on suggestions by Peter Hurley.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add 8250 MTK UART driver to support earlycon device tree.
Earlycon take effect by
  add "earlycon" in kernel boot argument
  add "linux,sdtout-path" property in device tree file
Signed-off-by: NEddie Huang <eddie.huang@mediatek.com>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

8250-like uart driver may call early_serial8250_setup to
reuse 8250_early.c character output function.
Signed-off-by: NEddie Huang <eddie.huang@mediatek.com>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The mtk 8250 needs two clocks, one for providing the baudrate and
one that needs to be enabled for register accesses. The latter has
not been supported, this patch adds support for it. It is optional
for now since not all SoCs provide a bus clock.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The pm_runtime callbacks already enable and disable the device.
Use them in probe() and remove() instead of duplicating the
code. This allows us to concentrate more code for enabling/disabling
the UART in a single place.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When a struct device * is present clk_get should be used rather
than of_clk_get. Use the devm variant of this function to be able to
drop the clk_put in the error and remove pathes. While at it fix
a wrong error message.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the driver has probed successfully the clk pointer is always valid,
so no need to test for it.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The rx_running flag should show if DMA is currently active. However
there is a window between when the flag is set/cleared and when
the DMA is started/stopped. Because the flag is queried from both
hard and soft irq contexts, the driver can make incorrect
decisions and do things like start a DMA transfer using a buffer
that is already setup to be used for a DMA transfer.

This patch adds a spinlock to synchronize the rx_running flag and
close the above mentioned window.
Signed-off-by: NJohn Ogness <john.ogness@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove CONFIG_SERIAL_DETECT_IRQ and CONFIG_SERIAL_MANY_PORTS, and
substitute all references to the proper 8250 Kconfig options.  Now, the
actual Kconfig dependencies are not hidden when reading the code and
static analyzers are less confused.
Signed-off-by: NValentin Rothberg <valentinrothberg@gmail.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This file local CPP identifier is not referenced anywhere else, so we
can safely remove it.
Signed-off-by: NValentin Rothberg <valentinrothberg@gmail.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
combined to act as a single 16 port chip. Therefor one chip is configured
as master the second as slave by connecting the mode pin to VCC (master)
or GND (slave).

Then the master chip is reporting a different device-id depending on
whether a slave is detected or not. The UARTs 8-15 are addressed from
0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
address all 16 ports as before.

See: https://www.exar.com/common/content/document.ashx?id=1587 page 11
Signed-off-by: NSoeren Grunewald <soeren.grunewald@desy.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add cases for UPIO_MEM32BE wherever there are currently cases handling
UPIO_MEM32.
Signed-off-by: NKevin Cernekee <cernekee@gmail.com>
Reviewed-by: NPeter Hurley <peter@hurleysoftware.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NRob Herring <robh@kernel.org>

Serial ports of F81504/F81508/F81512 will failed when wakeup from S3(STR).

It's due to when the system wakeup from S3(STR), this PCI device's
configuration space from 0x40 to 0x40 + max_port * 0x08 should be
re-configured.

We move all initialization from pci_fintek_setup() to pci_fintek_init() and
set it to pci_serial_quirks .init section. It's will re-init this device when
system wakeup from pciserial_resume_ports().
Signed-off-by: NPeter Hung <hpeter+linux_kernel@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Document the expected behavior of kernel command lines of the forms:
    console=uart[8250],io|mmio|mmio32,<addr>[,options]
    console=uart[8250],<addr>[,options]
and
    earlycon=uart[8250],io|mmio|mmio32,<addr>[,options]
    earlycon=uart[8250],<addr>[,options]
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Restore undocumented behavior of kernel command line parameters of
the forms:
    console=uart[8250],io|mmio|mmio32,<addr>[,options]
    console=uart[8250],<addr>[,options]
where 'options' have not been specified; in this case, the hardware
is assumed to be initialized.

Fixes: c7cef0a8 ("console: Add extensible console matching")
Reported-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The clock rate is requested from a property called
"clock-frequency" in both dw8250_probe_of and
dw8250_probe_acpi. Moving the requests to dw8250_probe.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>