linux-stable.git/include/linux/serial_reg.h, branch master Linux kernel stable tree UAPI: (Scripted) Disintegrate include/linux 2012-10-13T09:46:48+00:00 David Howells dhowells@redhat.com 2012-10-13T09:46:48+00:00 607ca46e97a1b6594b29647d98a32d545c24bdff Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Michael Kerrisk <mtk.manpages@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com> 
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Michael Kerrisk <mtk.manpages@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Dave Jones <davej@redhat.com>
serial: add OMAP-specific defines 2012-09-06T16:17:01+00:00 Felipe Balbi balbi@ti.com 2012-09-06T12:45:22+00:00 a0f38b87de1df05acf2e3cc23ee2f02a18d80c85 OMAP has some extra Interrupt types which can be really useful for SW. Let's define them so we can later use those in OMAP's serial driver. Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
OMAP has some extra Interrupt types which can
be really useful for SW. Let's define them
so we can later use those in OMAP's serial driver.

Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: Support the EFR-register of XR1715x uarts. 2011-09-22T22:50:38+00:00 Søren Holm sgh@sgh.dk 2011-09-02T20:55:37+00:00 06315348b16178e4c006e7892ef8e5e65f49c66a The EFR (Enhenced-Features-Register) is located at a different offset than the other devices supporting UART_CAP_EFR. This change add a special setup quick to set UPF_EXAR_EFR on the port. UPF_EXAR_EFR is then used to the port type to PORT_XR17D15X since it is for sure a XR17D15X uart. Signed-off-by: Søren Holm <sgh@sgh.dk> Acked-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
The EFR (Enhenced-Features-Register) is located at a different offset
than the other devices supporting UART_CAP_EFR. This change add a special
setup quick to set UPF_EXAR_EFR on the port. UPF_EXAR_EFR is then used to
the port type to PORT_XR17D15X since it is for sure a XR17D15X uart.

Signed-off-by: Søren Holm <sgh@sgh.dk>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
tty/serial: Fix break handling for PORT_TEGRA 2011-05-19T23:51:02+00:00 Stephen Warren swarren@nvidia.com 2011-05-17T22:12:37+00:00 5f873bae704cf8b7cbd64b5720912266286c9146 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> 
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>
tty/serial: Add explicit PORT_TEGRA type 2011-05-19T23:51:01+00:00 Stephen Warren swarren@nvidia.com 2011-05-17T22:12:36+00:00 4539c24fe4f92c09ee668ef959d3e8180df619b9 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> 
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>
omap: Serial: Define register access modes in LCR 2010-11-30T22:11:49+00:00 Andrei Emeltchenko andrei.emeltchenko@nokia.com 2010-11-30T22:11:49+00:00 662b083a87a3489f3f19c6e0651c1b99b0de5df0 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> 
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>
OMAP: Serial: Define OMAP uart MDR1 reg and remove magic numbers 2010-11-30T22:11:49+00:00 Andrei Emeltchenko andrei.emeltchenko@nokia.com 2010-11-30T22:11:49+00:00 498cb95175c29ed96bf32f30df2d11ec1c7f3879 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> 
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>
hsu: driver for Medfield High Speed UART device 2010-08-10T20:47:46+00:00 Feng Tang feng.tang@intel.com 2010-07-27T07:20:22+00:00 d843fc6e9dc9bee7061b6833594860ea93ad98e1 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> 
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>
tree-wide: fix assorted typos all over the place 2009-12-04T14:39:55+00:00 André Goddard Rosa andre.goddard@gmail.com 2009-11-14T15:09:05+00:00 af901ca181d92aac3a7dc265144a9081a86d8f39 That is "success", "unknown", "through", "performance", "[re|un]mapping" , "access", "default", "reasonable", "[con]currently", "temperature" , "channel", "[un]used", "application", "example","hierarchy", "therefore" , "[over|under]flow", "contiguous", "threshold", "enough" and others. Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.

Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
serial@ add OMAP wakeup-enable register 2009-06-22T18:32:24+00:00 Kevin Hilman khilman@deeprootsystems.com 2009-06-22T17:42:42+00:00 099d5270897606473d63091afcc63f53ee1894bc 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> 
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>