When a break is received, Tegra's UART apparently fills the FIFO with
0 bytes. These must be drained so that they aren't interpreted as actual
data received. This allows e.g. MAGIC_SYSRQ to work on Tegra's UARTs.
v2: Added FIXME comment to clear_rx_fifo
Originally-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tegra's UART is currently auto-detected as PORT_XSCALE due to register
bit UART_IER.UUE being writable. However, the Tegra documentation states
that this register bit is reserved. Hence, we should not program it.
Instead, the documentation specifies that the UART is 16550 compatible.
However, Tegra does need register bit UART_IER.RTOIE set, which is not
enabled by any 16550 port type. This was not noticed before, since
PORT_XSCALE enables CAP_UUE, which conflates both UUE and RTOIE bit
programming.
This change defines PORT_TEGRA that doesn't set UART_CAP_UUE, but does
set UART_CAP_RTOIE, which is a new capability indicating that the RTOIE
bit needs to be enabled.
Based-on-code-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Access to some registers depends on register access mode
Three different modes are available for OMAP (at least)
• Operational mode LCR_REG[7] = 0x0
• Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF
• Configuration mode B LCR_REG[7] = 0x1 and LCR_REG[7:0] = 0xBF
Define access modes and remove redefinitions and magic numbers
in serial drivers (and later in bluetooth driver).
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Define MDR1 register serial definitions used in serial and
bluetooth drivers.
Change magic number to ones defined in serial_reg for omap1/2
serial driver.
Remove redefined MDR1 register definitions in omap-serial driver.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: G, Manjunath Kondaiah <manjugk@ti.com>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This is a PCI & UART driver, which suppors both PIO and DMA mode
UART operation. It has 3 identical UART ports and one internal
DMA controller.
Current FW will export 4 pci devices for hsu: 3 uart ports and 1
dma controller, each has one IRQ line. And we need to discuss the
device model, one PCI device covering whole HSU should be a better
model, but there is a problem of how to export the 4 IRQs info
Current driver set the highest baud rate to 2746800bps, which is
easy to scale down to 115200/230400.... To suport higher baud rate,
we need add special process, change DLAB/DLH/PS/DIV/MUL registers
all together.
921600 is the highest baud rate that has been tested with Bluetooth
modem connected to HSU port 0. Will test more when there is right
BT firmware.
Current version contains several work around for A0's Silicon bugs
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add the wakeup enable register to the list of OMAP-specific UART
registers. This is to support forthcoming OMAP PM enhancements which
use the wakeup feature of the OMAP's 8250-based UART.
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reading the LSR clears the break, parity, frame error, and overrun bits in
the 8250 chip, but these are not being saved in all places that read the
LSR. Same goes for the MSR delta bits. Save the LSR bits off whenever the
lsr is read so they can be handled later in the receive routine. Save the
MSR bits to be handled in the modem status routine.
Also, clear the stored bits and clear the interrupt registers before
enabling interrupts, to avoid handling old values of the stored bits in the
interrupt routines.
[akpm@linux-foundation.org: clean up pre-existing code]
Signed-off-by: Corey Minyard <minyard@acm.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Yinghai Lu <yinghai.lu@sun.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Serial driver patch for the PMC-Sierra MSP71xx devices.
There are three different fixes:
1 Fix for DesignWare APB THRE errata: In brief, this is a non-standard
16550 in that the THRE interrupt will not re-assert itself simply by
disabling and re-enabling the THRI bit in the IER, it is only re-enabled
if a character is actually sent out.
It appears that the "8250-uart-backup-timer.patch" in the "mm" tree
also fixes it so we have dropped our initial workaround. This patch now
needs to be applied on top of that "mm" patch.
2 Fix for Busy Detect on LCR write: The DesignWare APB UART has a feature
which causes a new Busy Detect interrupt to be generated if it's busy
when the LCR is written. This fix saves the value of the LCR and
rewrites it after clearing the interrupt.
3 Workaround for interrupt/data concurrency issue: The SoC needs to
ensure that writes that can cause interrupts to be cleared reach the UART
before returning from the ISR. This fix reads a non-destructive register
on the UART so the read transaction completion ensures the previously
queued write transaction has also completed.
Signed-off-by: Marc St-Jean <Marc_St-Jean@pmc-sierra.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!