In preparation to convert SA1100 to sparse irq, set .nr_irqs for each machine
and explicitly include mach/irqs.h as needed.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds clk_prepare/clk_unprepare calls to the serial/pxa
driver by using the helper functions clk_prepare_enable and
clk_disable_unprepare.
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

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>

When kernel reboot, tty circular buffer is reset before last TX DMA interrupt is called,
while the buffer tail is updated in TX DMA interrupt handler. So, don't update the buffer
tail if it is reset.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes:

WARNING: drivers/tty/serial/built-in.o(.data+0x30): Section mismatch in reference from the variable vt8500_platform_driver to the function .init.text:vt8500_serial_probe()
The variable vt8500_platform_driver references
the function __init vt8500_serial_probe()

And mark the remove pointer while we are here.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The two callers to serial_out_sync() have a struct port right
there in scope, but then pass in a struct 8250_port which then
is locally resolved back to a struct port.

Delete the needless back and forth and just pass in the struct
port directly.  Rename the function to have "_port" in its
name, so the name <--> args relationship is consistent with the
other serial_in/out vs serial_port_in/out function classes.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The serial_in and serial_out helpers are expecting to operate
on an 8250_port struct.  These in turn go after the contained
normal port struct which actually has the actual in/out accessors.

But what is happening in some cases, is that a function is passed
in a port struct, and it runs container_of to get the 8250_port
struct, and then it uses serial_in/out helpers on that.  But when
you do, it goes full circle, since it jumps back inside the 8250_port
to find the contained port struct (which we already knew!).

So, if we are operating in a scope where we know the struct port,
then use the serial_port_in/out helpers and avoid the bouncing
around.  If we don't have the struct port handy, and it isn't
worth making a local for it, then just leave things as-is which
uses the serial_in/out helpers that will resolve the 8250_port
onto the struct port.

Mostly, gcc figures this out on its own -- so this doesn't bring to
the table any revolutionary runtime delta.  However, it is somewhat
misleading to always hammer away on 8250 structs, when the actual
underlying property isn't at all 8250 specific -- and this change
makes that clear.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The serial_8250_port struct contains within a serial_port struct
and many times one or the other, or both are in scope within
functions via a passed in arg, or via container_of.

However there are a lot of cases where we have access directly
to the port pointer, but yet go through the parent 8250_port
structure instead to get it.  These should just use the port
struct directly.

Similarly there are cases where it makes sense (from a code
cleanliness point of view) to declare a local for the port
struct, so we aren't going through the parent 8250_port struct
repeatedly to get to it.

We get a small reduction in text size, but it appears that
gcc was smart enough to internally be doing most of this
already, so the readability improvement is the larger gain.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These might have worked some magic with an ancient gcc back in
1992, but "objdump --disassemble" on gcc 4.6 on x86-64 shows
identical output before and after this commit.  Send the casts
and their hysterical rasins to the bitbucket.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently 8250.c has serial_in and serial_out as shortcuts
to doing the port I/O.  They are implemented as macros a
ways down in the file.  This isn't by accident, but is
implicitly required, so cpp doesn't mangle other instances
of the common string "serial_in", as it exists as a field
in the port struct itself.

The above mangling avoidance violates the principle of least
surprise, and it also prevents the shortcuts from being
relocated up to the top of file, or into 8250.h -- either
being a better location than the current one.

Move them to 8250.h so other 8250-like drivers can also use
the shortcuts, and in the process, make the conflicting
names go away by using static inlines instead of macros.
The object file size remains unchanged with this modification.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is the last traces of pausing I/O that we had back some
twenty years ago.  Probably was only required for 8MHz ISA
cards running "on the edge" at 12MHz.  Anyway it hasn't been
in use for years, so lets just bury it for good.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Document default_baud and user_uartclk module parameters.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Rather than hardcode 9600, use the existing default_baud parameter (which
also defaults to 9600).
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

For cases where boards with non-default clocks are not yet added to the kernel
or when the clock varies across hardware revisions, it is useful to be
able to specify the UART clock on the kernel command line.

Add the user_uartclk parameter and prefer it, if set, to the default and
board specific UART clock settings. Specify user_uartclock on the command-line
with "pch_uart.user_uartclk=48000000".
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for the Fish River Island II (FRI2) UART clock following the CM-iTC
quirk handling mechanism. Depending on the firmware installed on the device, the
FRI2 uses a 48MHz or a 64MHz UART clock. This is detected with DMI strings.

Add similar UART clock quirk handling to the pch_console_setup() function to
enable kernel messages on boards with non-standard UART clocks.

Per Alan's suggestion, abstract out UART clock selection into
pch_uart_get_uartclk() to avoid code duplication.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The term "base baud" refers to the fastest baud rate the device can communicate
at. This is clock/16. pch_uart is using base_baud as the clock itself. Rename
the variables to be semantically correct.
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
CC: Tomoya MORINAGA <tomoya.rohm@gmail.com>
CC: Feng Tang <feng.tang@intel.com>
CC: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The runtime PM of sh-sci devices is enabled when sci_probe() returns,
so the pm_runtime_put_sync() executed by driver_probe_device()
attempts to suspend the device.  Then, in some situations, a
diagnostic message is printed to the console by one of the runtime
suspend routines handling the sh-sci device, which causes synchronous
runtime resume to be started from the device's own runtime suspend
callback.  This causes rpm_resume() to be run eventually, which sees
the RPM_SUSPENDING status set by rpm_suspend() and waits for it to
change.  However, the device's runtime PM status cannot change at
that point, because the routine that has set it waits for the
rpm_suspend() to return.  A deadlock occurs as a result.

To avoid that make sci_init_single() increment the device's
runtime PM usage counter, so that it cannot be suspended by
driver_probe_device().  That counter has to be decremented
eventually, so make sci_startup() do that before starting to
actually use the device and make sci_shutdown() increment it
again before returning to balance the incrementation carried out by
sci_startup().
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The PowerPC legacy iSeries platform is being removed so this is no
longer selectable.

Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

In addition to the /32 prescaler, the MPC5200B supports a second
baudrate prescaler /4 to reach higher baudrates.

The current calculation (introduced with commit 0d1f22e4) in the kernel
preferes this low prescaler as often as possible, but with some
imprecise counterparts the communication on low baudrates fails.

According a support-mail from freescale the low prescaler (/4) allows
just 1% tolerance in bittiming in contrast to 4% of the high prescaler
(/32).  The prescaler not only affects the baudrate-calculation, but
also the sampling of the bits on the wire.

With this patch, we use the slightly less precise, but higher tolerant
prescaler calculation on low baudrates up to (and including) 115200 baud
and the more precise calculation above.

Tested on a custom MPC5200B board with "fsl,mpc5200b-psc-uart".

Calculation Examples with prescaler (PS) 4 and 32 and divisor (DIV) on
various baudrates. Real stands for the real baudrate generated and Diff
for the differences between:
     50 Baud PS 32 DIV 0xa122 Real      50 Diff   0.00%
     75 Baud PS 32 DIV 0x6b6c Real      75 Diff   0.00%
    110 Baud PS 32 DIV 0x493e Real     110 Diff   0.00%
    134 Baud PS 32 DIV 0x3c20 Real     133 Diff   0.75%
    150 Baud PS 32 DIV 0x35b6 Real     150 Diff   0.00%
    200 Baud PS 32 DIV 0x2849 Real     199 Diff   0.50%
    300 Baud PS  4 DIV 0xd6d8 Real     300 Diff   0.00%
             PS 32 DIV 0x1adb Real     300 Diff   0.00%
    600 Baud PS  4 DIV 0x6b6c Real     600 Diff   0.00%
             PS 32 DIV 0x0d6e Real     599 Diff   0.17%
   1200 Baud PS  4 DIV 0x35b6 Real    1200 Diff   0.00%
             PS 32 DIV 0x06b7 Real    1199 Diff   0.08%
   1800 Baud PS  4 DIV 0x23cf Real    1799 Diff   0.06%
             PS 32 DIV 0x047a Real    1799 Diff   0.06%
   2400 Baud PS  4 DIV 0x1adb Real    2400 Diff   0.00%
             PS 32 DIV 0x035b Real    2401 Diff - 0.04%
   4800 Baud PS  4 DIV 0x0d6e Real    4799 Diff   0.02%
             PS 32 DIV 0x01ae Real    4796 Diff   0.08%
   9600 Baud PS  4 DIV 0x06b7 Real    9598 Diff   0.02%
             PS 32 DIV 0x00d7 Real    9593 Diff   0.07%
  19200 Baud PS  4 DIV 0x035b Real   19208 Diff - 0.04%
             PS 32 DIV 0x006b Real   19275 Diff - 0.39%
  38400 Baud PS  4 DIV 0x01ae Real   38372 Diff   0.07%
             PS 32 DIV 0x0036 Real   38194 Diff   0.54%
  57600 Baud PS  4 DIV 0x011e Real   57692 Diff - 0.16%
             PS 32 DIV 0x0024 Real   57291 Diff   0.54%
  76800 Baud PS  4 DIV 0x00d7 Real   76744 Diff   0.07%
             PS 32 DIV 0x001b Real   76388 Diff   0.54%
 115200 Baud PS  4 DIV 0x008f Real  115384 Diff - 0.16%
             PS 32 DIV 0x0012 Real  114583 Diff   0.54%
 153600 Baud PS  4 DIV 0x006b Real  154205 Diff - 0.39%
             PS 32 DIV 0x000d Real  158653 Diff - 3.29%
 230400 Baud PS  4 DIV 0x0048 Real  229166 Diff   0.54%
             PS 32 DIV 0x0009 Real  229166 Diff   0.54%
 307200 Baud PS  4 DIV 0x0036 Real  305555 Diff   0.54%
             PS 32 DIV 0x0007 Real  294642 Diff   4.09%
 460800 Baud PS  4 DIV 0x0024 Real  458333 Diff   0.54%
             PS 32 DIV 0x0005 Real  412500 Diff  10.48%
 500000 Baud PS  4 DIV 0x0021 Real  500000 Diff   0.00%
             PS 32 DIV 0x0004 Real  515625 Diff - 3.13%
 576000 Baud PS  4 DIV 0x001d Real  568965 Diff   1.22%
             PS 32 DIV 0x0004 Real  515625 Diff  10.48%
 614400 Baud PS  4 DIV 0x001b Real  611111 Diff   0.54%
             PS 32 DIV 0x0003 Real  687500 Diff -11.90%
 921600 Baud PS  4 DIV 0x0012 Real  916666 Diff   0.54%
             PS 32 DIV 0x0002 Real 1031250 Diff -11.90%
1000000 Baud PS  4 DIV 0x0011 Real  970588 Diff   2.94%
             PS 32 DIV 0x0002 Real 1031250 Diff - 3.13%
1152000 Baud PS  4 DIV 0x000e Real 1178571 Diff - 2.31%
             PS 32 DIV 0x0002 Real 1031250 Diff  10.48%
1500000 Baud PS  4 DIV 0x000b Real 1500000 Diff   0.00%
             PS 32 DIV 0x0001 Real 2062500 Diff -37.50%
2000000 Baud PS  4 DIV 0x0008 Real 2062500 Diff - 3.13%
             PS 32 DIV 0x0001 Real 2062500 Diff - 3.13%
2500000 Baud PS  4 DIV 0x0007 Real 2357142 Diff   5.71%
             PS 32 DIV 0x0001 Real 2062500 Diff  17.50%
3000000 Baud PS  4 DIV 0x0006 Real 2750000 Diff   8.33%
             PS 32 DIV 0x0001 Real 2062500 Diff  31.25%
3500000 Baud PS  4 DIV 0x0005 Real 3300000 Diff   5.71%
             PS 32 DIV 0x0001 Real 2062500 Diff  41.07%
4000000 Baud PS  4 DIV 0x0004 Real 4125000 Diff - 3.13%
             PS 32 DIV 0x0001 Real 2062500 Diff  48.44%
Signed-off-by: NFrank Benkert <frank.benkert@avat.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All of them do not use the ugly interface defined in that header.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It uses pointers to pci_dev, but compiler complains it doesn't know
it:
In file included from .../m32r_sio.c:53:
.../m32r_sio.h:21: warning: "struct pci_dev" declared inside parameter list
.../m32r_sio.h:21: warning: its scope is only this definition or declaration, which is probably not what you want
.../m32r_sio.h:22: warning: "struct pci_dev" declared inside parameter list
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We want to know the value of the atomic variable in intr_connect after
the increment. But atomic_inc doesn't, per definition, return the
value.  It is just a pure coincidence that ia64 defines atomic_inc as
atomic_inc_return.

So fix this mistake by using atomic_inc_return properly.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Checking if tty->index is in bounds is not needed. The tty has the
index set in the initial open. This is done in get_tty_driver. And it
can be only in interval <0,driver->num).

So remove the tests which check exactly this interval. Some are
left untouched as they check against the current backing device count.
(Leaving apart that the check is racy in most of the cases.)
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

All num, magic and owner are set by alloc_tty_driver. No need to
re-set them on each allocation site.

pti driver sets something different to what it passes to
alloc_tty_driver. It is not a bug, since we don't use the lines
parameter in any way. Anyway this is fixed, and now we do the right
thing.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Acked-by: NTilman Schmidt <tilman@imap.cc>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The following commit: be4b0281
(tty: serial: OMAP: block idle while the UART is transferring data in PIO mode),
is introducing an oops if OMAP is booted using device tree blob because
the pdata will not be initialized.

Check if pdata is set before de-referencing it.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Parse uart device id from alias in DTS file.
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>

The API model is changed from:

p = pinctrl_get(dev, "state1");
pinctrl_enable(p);
...
pinctrl_disable(p);
pinctrl_put(p);
p = pinctrl_get(dev, "state2");
pinctrl_enable(p);
...
pinctrl_disable(p);
pinctrl_put(p);

to this:

p = pinctrl_get(dev);
s1 = pinctrl_lookup_state(p, "state1");
s2 = pinctrl_lookup_state(p, "state2");
pinctrl_select_state(p, s1);
...
pinctrl_select_state(p, s2);
...
pinctrl_put(p);

This allows devices to directly transition between states without
disabling the pin controller programming and put()/get()ing the
configuration data each time. This model will also better suit pinconf
programming, which doesn't have a concept of "disable".

The special-case hogging feature of pin controllers is re-written to use
the regular APIs instead of special-case code. Hence, the pinmux-hogs
debugfs file is removed; see the top-level pinctrl-handles files for
equivalent data.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinctrl_register_mappings() already requires that every mapping table
entry have a non-NULL name field.

Logically, this makes sense too; drivers should always request a specific
named state so they know what they're getting. Relying on getting the
first mentioned state in the mapping table is error-prone, and a nasty
special case to implement, given that a given the mapping table may define
multiple states for a device.

Remove a small part of the documentation that talked about optionally
requesting a specific state; it's mandatory now.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.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>

Without that fix machines having a s3c2442 CPU have something
  like that in dmesg:
    samsung-uart s3c2440-uart.0: could not find driver data
    samsung-uart s3c2440-uart.1: could not find driver data
    samsung-uart s3c2440-uart.2: could not find driver data
  And serial is never initialized.

The previous log was obtained trough early printk on the gta02
  machine.
Signed-off-by: NDenis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Correct spelling "receieve" to "receive" in
drivers/tty/serial/sn_console.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

drivers/tty/serial/mux.c included 'linux/tty.h' twice, remove
the duplicate.
Signed-off-by: NDanny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This variable spread on every SoC that is using the atmel_serial.c
driver can be included directly into the latter.

This will allow to compile multiple soc in the same kernel.
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: kernel@avr32linux.org

This patch allows the system to boot and enables the console and at least
some hardware drivers, as well as some platform error handling.

Tested on a variety of SGI Altix system without issues.
Signed-off-by: NDimitri Sivanich <sivanich@sgi.com>
Tested-by: NRaymund Will <rw@suse.de>
Signed-off-by: NTony Luck <tony.luck@intel.com>

We changed the signature of the pin multiplexing functions to
handle any pin business, so fix up the Sirf driver to call this
new interface and rename some variables to make the semantics
understandable.

Cc: linux-serial@vger.kernel.org
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Correct spelling "receieve" to "receive" in
drivers/tty/serial/sn_console.c
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There are multiple users of this file from different source
paths now, and rather than have ../ paths in include statements,
just move the file to the linux header dir.
Suggested-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The receive FIFO wakeup latency estimate in the omap-serial driver is
three orders of magnitude too small.  This effectively prevents the
MPU from going to a low-power state when CONFIG_CPU_IDLE=y.  This is a
major power management regression and masks some other FIFO-related
bugs in the driver.

Fix by correcting the most egregious problem in the RX wakeup latency
estimate.  There are several other flaws in the estimator; these will
be fixed by a separate patch series intended for 3.4.

The difference in low-power states with this patch can be observed via
debugfs in pm_debug/count.

This estimate does not have any effect when CONFIG_CPU_IDLE=n.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Prevent OMAP UARTs from going idle while they are still transferring
data in PIO mode.  This works around an oversight in the OMAP UART
hardware present in OMAP34xx and earlier: an idle UART won't send a
wakeup when the TX FIFO threshold is reached.  This causes long delays
during data transmission when the MPU powerdomain enters a low-power
mode.  The MPU interrupt controller is not able to respond to
interrupts when it's in a low-power state, so the TX buffer is not
refilled until another wakeup event occurs.

This fix changes the erratum i291 DMA idle workaround.  Rather than
toggling between force-idle and no-idle, it will toggle between
smart-idle and no-idle.  The important part of the workaround is the
no-idle part, so this shouldn't result in any change in behavior.

This fix should work on all OMAP UARTs.  Future patches intended for
the 3.4 merge window will make this workaround conditional on a
"feature" flag, and will use the OMAP36xx+ TX event wakeup support.

Thanks to Kevin Hilman <khilman@ti.com> for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the (default) PIO mode, use a one-byte RX FIFO threshold.  The OMAP
UART IP blocks do not appear to be capable of waking the system under
an RX timeout condition.  Since the previous RX FIFO threshold was 16
bytes, this meant that omap-serial.c did not become aware of any
received data until all those bytes arrived or until another UART
interrupt occurred.  This made the serial console and presumably other
serial applications (GPS, serial Bluetooth) unusable or extremely
slow.  A 1-byte RX FIFO threshold also allows the MPU to enter a
low-power consumption state while waiting for the FIFO to fill.

This can be verified using the serial console by comparing the
behavior when "0123456789abcde" is pasted in from another window, with
the behavior when "0123456789abcdef" is pasted in.  Since the former
string is less than sixteen bytes long, the string is not echoed for
some time, while the latter string is echoed immediately.

DMA operation is unaffected by this patch.

Thanks to Russell King - ARM Linux <linux@arm.linux.org.uk> for some
additional information on the standard behavior of the RX timeout
event, which was used to improve this commit description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>