To avoid lines with more than 80 characters and to make the
pl011_int() function more readable, move the workaround out into a
separate function.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The PL011 register UART_MIS is actually a bitwise AND of the
UART_RIS and the UART_MISC register.
Since the SBSA UART does not include the _MIS register, use the
two separate registers to get the same behaviour. Since we are
inside the spinlock and we read the _IMSC register only once, there
should be no race issue.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently the pl011_probe() function is relying on some AMBA IDs
and a device tree node to initialize the driver and a port.
Both features are not necessarily required for the driver:
- we lack AMBA IDs in the ARM SBSA generic UART and
- we lack a DT node in ACPI systems.
So lets refactor the function to ease later reuse.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Split the pl011_set_termios() function into smaller chunks to allow
easier reuse later when adding SBSA support.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Split the pl011_shutdown() function into smaller chunks to allow
easier reuse later when adding SBSA support.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Split the pl011_startup() function into smaller chunks to allow
easier reuse later when adding SBSA support.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Although we care about not unregistering the driver if there are
still ports connected during the .remove callback, we do miss this
check in the pl011_probe function. So if the current port allocation
fails, but there are other ports already registered, we will kill
those.
So factor out the port removal into a separate function and use that
in the probe function, too.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Mark Langsdorf <mlangsdo@redhat.com>
Tested-by: Naresh Bhat <nbhat@cavium.com>
Signed-off-by: Greg 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: Arnd Bergmann <arnd@arndb.de>
Acked-by: Eddie Huang <eddie.huang@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A configuration that enables earlycon but not the core console
code causes a link error:
drivers/built-in.o: In function `setup_earlycon':
drivers/tty/serial/earlycon.c:70: undefined reference to `uart_parse_earlycon'
That error can be triggered by the newly added samsung earlycon support,
which is missing a 'select' statement.
As suggested by Peter Hurley, solves the problem by moving the
'select SERIAL_EARLYCON' statement to the samsung console driver
option, as it is done by all other console drivers.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: b94ba0328d ("serial: samsung: Add support for early console")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function mctrl_gpio_init returns failure if the assignment to any
member of the gpio array results in an error pointer. So there is no
need to check for such error values in the other functions.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg 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 0aa525d118 ("tty: serial: 8250_core: read only
RX if there is something in the FIFO") but then reverted it later in
commit ca8bb4aefb ("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: ca8bb4aefb ("serial: 8250: Revert "tty: serial: 8250_core:
read only RX if there is something in the FIFO"")
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the call to dmaengine_slave_config() fails, then the DMA buffer will
not be freed/unmapped. Fix this by moving the code that stores the
address of the buffer in the tegra_uart_port structure to before the
call to dmaengine_slave_config().
Reported-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
it seems this is a more typical behaviour from reviewing other console
drivers.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
add overrun error's flag mark and parity's counter, we can show the
statistic from procfs node.
BTW, let the indentation of stick bits configuration look better.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In special condition, when cpu schedule into rx_tmo_process_tl or
rx_dma_complete_tl and all the receive dma tasks have done, it will
go into endless loop because no dma task cookie status be changed.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>From HW spec, when rxfifo's data is less than AFC_RX_THD(RX threshhold), RTS
signal is active. otherwise, RTS signal is inactive.
Crrently the RX threshhold is set as zero, so RTS has no chance to be
active. This patch replaces the default 0 by a positive number.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
differentiate difference port types by re-defining the status MARCO
or putting HW differences into private data of the related ports.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In RS485 mode, we may want to set the delay_rts_after_send value to 0.
In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but
this is exactly the expected behavior if we want no delay...
Moreover, if the value was set to non-zero value by device-tree or earlier
ioctl command, it was impossible to change it back to zero.
Reported-by: Sami Pietikäinen <Sami.Pietikainen@wapice.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: stable@vger.kernel.org # 3.2+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In commit 02730d3c05
(Merge 4.1-rc4 into tty-next), git mismerged some lines,
reintroducing a reference to the removed field
uart_amba_port.tx_irq_seen. This causes a build failure.
This patch removes the mismerged lines, restoring the code to what
was in tty-next (which was the intention).
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This code is no longer used now that mach-msm has been removed.
Delete it.
Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Daniel Walker <dwalker@fifo99.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Function tegra_uart_dma_channel_allocate() does not check that
dma_map_single() mapped the DMA buffer correctly. Add a check for this
and appropriate error handling.
Furthermore, if dmaengine_slave_config() (called by
tegra_uart_dma_channel_allocate()) fails, then memory allocated/mapped
is not freed/unmapped. Therefore, call tegra_uart_dma_channel_free()
instead of just dma_release_channel() if dmaengine_slave_config() fails.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are two issues in the shutdown path of the UARTs which are:
1. The function tegra_uart_shutdown() calls tegra_uart_flush_buffer()
to stop DMA TX transfers. However, tegra_uart_flush_buffer() is
called after the DMA channels have already been freed and so actually
does nothing.
2. The function that frees the DMA channels
(tegra_uart_dma_channel_free()), unmaps the dma buffer before
freeing the DMA channel and does not ensure the DMA has been
stopped.
Resolve this by fixing the code in tegra_uart_dma_channel_free() to
ensure the DMA is stopped, free the DMA channel and then unmap the DMA
buffer. Finally, remove the unnecessary call to tegra_uart_flush_buffer().
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DMA cookie for the RX channel is being used by the TX channel.
Therefore, fix driver to use the correct DMA cookie for the TX channel.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function tty_insert_flip_string() takes an argument "size" which is
of type size_t. This is an unsigned type. Update the count,
rx_bytes_requested and tx_bytes_requested in the tegra serial driver to
be unsigned integers so that an unsigned type is passed to
tty_insert_flip_string().
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The tegra serial driver has two paths through which receive data is
copied up to the tty layer. These are:
1. DMA completion callback
2. UART RX interrupt
A UART RX interrupt occurs for either RX_TIMEOUT (data has been sitting
in the Rx FIFO for more than 4 character times without being read
because there is not enough data to reach the trigger level), End of
Receive Data event (receiver detects that data stops coming in for more
than 4 character times) or a receive error.
In the RX interrupt path, the following happens ...
- All RX DMA transfers are stopped
- Any data in the DMA buffer and RX FIFO are copied up to the tty layer.
- DMA is restarted/primed for the RX path
In the DMA completion callback, the DMA buffer is copied up to the tty
layer but there is no check to see if the RX interrupt could have
occurred between the DMA interrupt firing the the DMA callback running.
Hence, if a RX interrupt was to occur shortly after the DMA completion
interrupt, it is possible that the RX interrupt path has already copied
the DMA buffer before the DMA callback has been called. Therefore, when
the DMA callback is called, if the DMA is already in-progress, then this
indicates that the UART RX interrupt has already occurred and there is
nothing to do in the DMA callback. This race condition can cause
duplicated data to be received.
Signed-off-by: Shardar Shariff Md <smohammed@nvidia.com>
[jonathanh@nvidia.com: Moved async_tx_ack() call to after check to see
if DMA has completed because if the DMA is in progress we do not need
to ACK yet. Changed the print from dev_info to dev_debug. Updated
changelog to add more commentary on the race condition based upon
feedback from author.]
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is only necessary to read data from the dma buffer when the count
value is non-zero and hence, tegra_uart_copy_rx_to_tty() so only be
called when this is the case.
Although, this was being tested for in two places, there is a third
place where this was not tested. However, instead of adding another
if-statement prior to calling tegra_uart_copy_rx_to_tty(), move the test
inside the function.
Signed-off-by: Shardar Shariff Md <smohammed@nvidia.com>
[jonathanh@nvidia.com: Re-worked patch to move the check for the count
value inside the function tegra_uart_copy_rx_to_tty(). Updated
changelog with more commentary.]
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For all tegra devices (up to t210), there is a hardware issue that
requires software to wait for 3 UART clock periods after enabling
the TX fifo, otherwise data could be lost.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For all tegra devices (up to t210), there is a hardware issue that
requires software to wait for 32 UART clock periods for the flush
to propagate otherwise TX data could be post. Add a helper function
to wait for N UART clock periods and update delay following FIFO
flush to be 32 UART clock cycles.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The port.type has already been set by of_platform_serial_setup()
called from a few lines above.
Setting it to the same value is redundant.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg 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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Early console functions are only used during the early boot stage.
This change just saves a small amount of memory footprint.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg 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: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Staticize symbols not exported and not used outside of file.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code it refers to was removed in commit b545e4f406 ("serial:
sh-sci: Compute overrun_bit without using baud rate algo").
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
error_mask is the union of all error indicating bits in the SCxSR
register, while overrun_mask may apply to a different register (SCLSR),
depending on the SCI variant.
Hence overrun_mask should only be ORed into error_mask if it applies to
the SCxSR register.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The various SCI implementations use 3 different methods to signal
overrun errors:
- Bit SCI_ORER in register SCxSR on SCI,
- Bit SCIFA_ORER in register SCxSR on SCIFA and SCIFB, and SCIF on
SH7705/SH7720/SH7721,
- Bit SCLSR_ORER in (optional!) register SCLSR on (H)SCIF.
However:
1. sci_handle_fifo_overrun()
a. handles (H)SCIF and SCIFA/SCIFB only,
b. treats SCIF on SH7705/SH7720/SH7721 incorrectly,
2. sci_mpxed_interrupt()
a. treats SCIF on SH7705/SH7720/SH7721 incorrectly,
b. ignores that not all SCIFs have the SCLSR register, causing
"Invalid register access" WARN()ings.
To fix the above:
1. Determine and store the correct register enum during
initialization,
2. Replace the duplicated buggy switch statements by using the stored
register enum,
3. Add the missing existence check to sci_mpxed_interrupt().
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the missing overrun bit definition for (H)SCIF.
Replace overrun_bit by overrun_mask, so we can use the existing
defines instead of hardcoded values.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the missing overrun error bit in SCxSR on SCIFA/SCIFB and SCIF on
SH7705/SH7720/SH7721.
Document what the corresponding bit(s) on plain SCIF are used for.
Sort the components of SCIF_DEFAULT_ERROR_MASK by reverse definition
order.
Replace the hardcoded values in the SCxSR_*_CLEAR macros by proper
defines. Use bit masks (negations of sets of bits) to make it more
obvious which bits are being cleared.
Assembler output (on sh) was compared before and after this commit:
- For the first branch of the big "#if defined(...) || ..." construct,
the code has changed slightly, as 32-bit bitmasks can be loaded in a
single instruction, unlike the old large 16-bit constants (the SCxSR
register is 16 bit, so we don't care about the top 16 bits),
- For the second branch, the generated code is identical.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the register definitions for the Serial Port Control and Data
Registers on SCIFA/SCIFB, which are needed for RTS/CTS pin control.
Extracted from patches by Magnus Damm <damm+renesas@opensource.se>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add the missing register bit definitions to set the RTS pin and read the
CTS pin on (H)SCIF.
Extracted from patches by Magnus Damm <damm+renesas@opensource.se>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move private register definitions and enums from the public
<linux/serial_sci.h> header file to the driver private "sh-sci.h" header
file.
The common Serial Control Register definitions are left in the public
header file, as they're needed to fill in plat_sci_port.scscr on legacy
systems not using DT.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We should not be doing assignments within an if () block
so fix up the code to not do this.
change was created using Coccinelle.
CC: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We should not be doing assignments within an if () block
so fix up the code to not do this.
change was created using Coccinelle.
CC: Pat Gefre <pfg@sgi.com>
CC: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
