This reverts commit 0324a821.

That commit tried to fix a deadlock problem when using
hci_ldisc, but it turns out the bug was in hci_ldsic
all along where it was calling ->write() from within
->write_wakeup() callback.

The problem is that ->write_wakeup() was called with
port lock held and ->write() tried to grab the same
port lock.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The lack of pm_runtime_resume handling for the device state leads into
device wake-up interrupts not working after a while for runtime PM.

Also, serial-omap is confused about the use of device_may_wakeup.
The checks for device_may_wakeup should only be done for suspend and
resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
events for PM runtime should always be enabled.

The lack of pm_runtime_resume handling leads into device wake-up
interrupts not working after a while for runtime PM.

Rather than try to patch over the issue of adding complex tests to
the pm_runtime_resume, let's fix the issues properly:

1. Make serial_omap_enable_wakeup deal with all internal PM state
   handling so we don't need to test for up->wakeups_enabled elsewhere.

   Later on once omap3 boots in device tree only mode we can also
   remove the up->wakeups_enabled flag and rely on the wake-up
   interrupt enable/disable state alone.

2. Do the device_may_wakeup checks in suspend and resume only,
   for runtime PM the wake-up events need to be always enabled.

3. Finally just call serial_omap_enable_wakeup and make sure we
   call it also in pm_runtime_resume.

4. Note that we also have to use disable_irq_nosync as serial_omap_irq
   calls pm_runtime_get_sync.

Fixes: 2a0b965c (serial: omap: Add support for optional wake-up)
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NSanjay Singh Rawat <sanjay.rawat@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Provided that the SER_RS485_RX_DURING_TX flag is not set, empty the
RX FIFO to prevent reading back the transmitted data.
Signed-off-by: NDimitris Lampridis <dlampridis@logikonlabs.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure that serial_omap_stop_rx() also disables RDI (Receiver Data Interrupt),
otherwise the interrupt handler will call serial_omap_rdi() to read the new data,
resulting in the transmission being echoed back.

When the half-duplex transmission is complete, in order to reverse the effects of
serial_omap_stop_rx(), we should re-enable:

  * the RX interrupts _without_ overwriting up->ier

  * the UART_LSR_DR bit of the up->port.read_status_mask
Signed-off-by: NDimitris Lampridis <dlampridis@logikonlabs.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the gpio is not yet available we better also
defer the probing in the rs485 case.
Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the info message about a missing wakeirq for uart is printed
every time the serial driver's startup function is called. This happens
multiple times and not just once.

This can cause lots of extra messages at boot time, slowing things down.  It is
caused by commit 2a0b965c (serial: omap: Add support for optional wake-up)
which was applied for v3.13-rc1.

This patch moves the infomessage to the probe function to display it
only once.
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: stable <stable@vger.kernel.org> # 3.13
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the info message about a missing wakeirq for uart is printed
every time the serial driver's startup function is called. This happens
multiple times and not just once.

This patch moves the infomessage to the probe function to display it
only once.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>,
Signed-off-by: NPhilippe Proulx <philippe.proulx@savoirfairelinux.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NPhilippe Proulx <philippe.proulx@savoirfairelinux.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If RS-485 is enabled, make the OMAP UART fire THR interrupts when both
TX FIFO and TX shift register are empty instead of polling the
equivalent status bit. This removes the burst of interrupt requests
seen at every end of transmission.

Also: the comment said that the TX FIFO trigger level was set at 16
characters when it's 32 in reality.
Signed-off-by: NPhilippe Proulx <philippe.proulx@savoirfairelinux.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

With the recent pinctrl-single changes, omaps can treat
wake-up events from deeper idle states as interrupts.

There's a separate "io chain" controller on most omaps
that stays enabled when the device hits off-idle and the
regular interrupt controller is powered off.

Let's add support for the optional second interrupt for
wake-up events. And then serial-omap can manage the
wake-up interrupt from it's runtime PM calls to avoid
spurious interrupts during runtime.

Note that the wake interrupt is board specific as it
uses the UART RX pin, and for omap3, there are six pin
options for UART3 RX pin.

Also Note that the legacy platform based booting handles
the wake-ups in the legacy mux driver and does not need to
pass the wake-up interrupt to the driver.

And finally, to pass the wake-up interrupt in the dts file,
either interrupt-map or the pending interrupts-extended
property needs to be passed. It's probably best to use
interrupts-extended when it's available.

Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This callback is unused by the serial core since pre-git days
and is not coming back. Delete it. Enabling wakeup on the
OMAP serial driver is done through other runpaths these days.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make Mode16 more preferred than Mode13, to match TRM baudrates table.
Signed-off-by: NAlexey Pelykh <alexey.pelykh@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix misnamed variable to eliminate confusion.
Signed-off-by: NAlexey Pelykh <alexey.pelykh@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit c4415084.

Kevin writes:
	Hmm, another OMAP serial patch that wasn't Cc'd to linux-omap
	where OMAP users might have seen it. :(

	I just bisected a strange problem in linux-next on OMAP3 down to
	this patch.  Reverting it fixes the problem.

	On OMAP3530 Beagle and Overo, after boot, doing a 'cat
	/proc/cpuinfo' was not returning to a prompt, suggesting
	something strange with the FIFO.  Hitting return gets me back to
	a prompt.

	Greg, this one should also be dropped from tty-next until it can
	be further investgated and the problem solved.
Reported-by: NKevin Hilman <khilman@linaro.org>
Cc: Dmitry Fink <finik@ti.com>
Cc: Alexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 908fd7e5.

Kevin writes:
	Greg, without a better justification in the changelog, I think
	this patch should be dropped from tty-next.
Reported-by: NKevin Hilman <khilman@linaro.org>
Cc: Ruchika Kharwar <ruchika@ti.com>
Cc: Alexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The recent patch to add RS485 contained a bug whereby the IER
interrupt was cleared down incorrectly.

This patch fixes the problem.
Signed-off-by: NMark Jackson <mpfj@newflow.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch adds RS485 support to the OMAP serial driver, as
defined in:-

Documentation/devicetree/bindings/serial/rs485.txt

When a UART transmitter is connected to (eg) a RS485 driver, it is
necessary to turn the driver on/off as quickly as possible.  This is
best achieved in the serial driver itself (rather than in userspace
where the latency can be quite large).

This patch allows a GPIO pin to be defined (via DT) that controls
the enabling of the driver at the start of a message, and disables
the driver when the message has been completed.

When RS485 is disabled, the RTS pin is set to on.
Signed-off-by: NMark Jackson <mpfj@newflow.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If earlyprintk is enabled and current UART is console port the platform
code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
avoid resuming of already active device, but now, driver initialization
will be performed in the wrong way:

	pm_runtime_enable(&pdev->dev);
    <-- PM runtime alowed (device state RPM_ACTIVE)
	if (omap_up_info->autosuspend_timeout == 0)
		omap_up_info->autosuspend_timeout = -1;
	device_init_wakeup(up->dev, true);
	pm_runtime_use_autosuspend(&pdev->dev);
	<-- update_autosuspend() will be called and it will disable device
        (device state RPM_SUSPENDED)
	pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
	<-- update_autosuspend() will be called which will re-enable device
        (device state RPM_ACTIVE), because autosuspend_timeout < 0

	pm_runtime_irq_safe(&pdev->dev);
	pm_runtime_get_sync(&pdev->dev);
	<-- will do nothing

Such behavior isn't expected by OMAP serial drivers and causes
unpredictable calls of serial_omap_runtime_suspend() and
serial_omap_runtime_resume().

Hence, fix it by allowing PM runtime only after all its parameters are
configured.

CC: Tony Lindgren <tony@atomide.com>
CC: Rajendra Nayak <rnayak@ti.com>
CC: Felipe Balbi <balbi@ti.com>
CC: Kevin Hilman <khilman@linaro.org>
Tested-by: NMark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Ensure the Interrupt handling routine return IRQ_HANDLED vs
IRQ_NONE.
Signed-off-by: NRuchika Kharwar <ruchika@ti.com>
Signed-off-by: NAlexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Otherwise serial driver would crash accessing platform_data that was
not initialized in functions like:

        serial_omap_pm(...)
        ...
        if (!state && pdata->enable_wakeup)
                   ^^^^^^^
        ...
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NAlexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The revision register is a 32 bit register. The serial_in() function reads
only the lower 16 bits of the register. This leads to an incorrect computation
of the Module revision.
Signed-off-by: NRuchika Kharwar <ruchika@ti.com>
[oleksandr.savchenko@ti.com: add some whitespaces]
Signed-off-by: NAlexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Current logic results in interrupt storm since the fifo
is constantly below the threshold level. Change the logic
to fill all the available spaces in the fifo as long as
we have data to minimize the possibilty of underflow and
elimiate excessive interrupts.
Signed-off-by: NDmitry Fink <finik@ti.com>
Signed-off-by: NAlexander Savchenko <oleksandr.savchenko@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

wer has TX wakeup bit available enable the same
by populating the necessary tx wakeup flag for the
applicable module ip blocks and use the same
while configuaring wer reg.

Also wer is not context restored, restore wer when
context is lost.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Kevin Hilman <kevin.hilman@linaro.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
(for drivers/tty changes)
Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.

Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the runtime_suspend function pdata is not being used, and
also blocks the function in device tree based booting. Fix it
by removing the unused pdata from the runtime_suspend function.

Further, context loss count is not being passed in pdata, so
let's just reinitialize the port every time for those case.
This can be further optimized later on for the device tree
case by adding detection for the hardware state and possibly
by adding a driver specific autosuspend timeout.

And doing this, we can then make the related dev_err into a
dev_dbg message instead of an error.

In order for the wake-up events to work, we also need to set
autosuspend_timeout to -1 if 0, and also device_init_wakeup()
as that's not being done by the platform init code for the
device tree case.

Note that this does not affect legacy booting, and in fact
might make it work for the cases where the context loss info
is not being passed in pdata.

Thanks to Kevin Hilman <khilman@linaro.org> for debugging
and suggesting fixes for the autosuspend_timeout and
device_init_wakeup() related initializiation.
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dereference to 'up' should be moved below the NULL test.
Introduced by commit ddd85e22
(serial: omap: prevent runtime PM for "no_console_suspend")
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A recent bug fix in 3.10, ddd85e22 "serial: omap: prevent runtime PM for
"no_console_suspend"", introduced a regression from an obvious typo:

drivers/tty/serial/omap-serial.c:1677:14: error: 'serial_omap_complete'
	undeclared here (not in a function)

This changes the incorrectly added macro to the one that we need instead.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NBin Liu <b-liu@ti.com>
Acked-by: Sourav Poddar<sourav.poddar@ti.com>
Tested-by: Sourav Poddar<sourav.poddar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The driver manages "no_console_suspend" by preventing runtime PM
during the suspend path, which forces the console UART to stay awake.
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

UART IP slave idle handling now taken care by runtime pm backend(hwmod layer)
so remove the hackery from the driver.

As discussed on the list, in future if dma mode needs to be brought
back to this driver, UART sysc handling needs to be updated in
framework such a way that no-idle/force idle profile can be supported.
Given the broken dma mode for OMAP uarts, its very unlikely.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRajendra nayak <rnayak@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>  # OMAP4/Panda
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Partially reverts 1776fd05
that introduced regression reported by Paul Walmsley.

This commit restores setting granularity in SCR register
and adds note about comments below being inconsistent with
actual code.
Signed-off-by: NAlexey Pelykh <alexey.pelykh@gmail.com>
Tested-by: NPaul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR validation on Tx, and Tx FIFO IRQ generation

Original configuration of Rx FIFO threshold contained an error
that resulted Rx threshold to be effectively set to 1 character
instead of 16 characters, as noted in comments.
Checking LSR to contain UART_LSR_THRE bit set caused issue when
not all UART_IER_THRI interrupts have been properly handled.
This caused gap in Tx data, visible on high baud rates using
oscilloscope.
Setting OMAP_UART_SCR_TX_EMPTY bit in SCR caused UART_IER_THRI
interrupt to be raised only when Tx FIFO and Tx shift registers
are empty.
Signed-off-by: NAlexey Pelykh <alexey.pelykh@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Original table in OMAP TRM named "UART Mode Baud Rates, Divisor
Values, and Error Rates" determines modes not for all common baud
rates. E.g. for 1000000 baud rate mode should be 16x, but according to
that table it's determined as 13x. According to current implementation
of mode divisor selection, after requesting 1000000 baudrate from
driver, later one will configure chip to use MODE13 divisor. Assuming
48Mhz as common UART clock speed, MODE13 divisor will effectively give
1230769 baudrate, what is quite far from desired 1000000 baudrate.
While with MODE16 divisor, chip will produce exact 1000000 baudrate.
In old driver that served UART devices (8250.c and serial_core.c) this
divisor could have been configured by user-space program, but in
omap_serial.c driver implementation this ability was not implemented
(afaik, by design) thus disallowing proper usage of MODE16-compatible
baudrates.
Signed-off-by: NAlexey Pelykh <alexey.pelykh@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now, we start converting tty buffer functions to actually use
tty_port. This will allow us to get rid of the need of tty in many
call sites. Only tty_port will needed and hence no more
tty_port_tty_get in those paths.

Now, the one where most of tty_port_tty_get gets removed:
tty_flip_buffer_push.

IOW we also closed all the races in drivers not using tty_port_tty_get
at all yet.

Also we move tty_flip_buffer_push declaration from include/linux/tty.h
to include/linux/tty_flip.h to all others while we are changing it
anyway.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some systems require the additional communication functionality of a
9-bit UART. For that we could use the "stick" (mark/space) parity
bit supported on omap serial device. When is set, if PARODD is set the
parity bit is always 1; if PARODD is not set, then the parity bit is
always 0.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We need to move this file to allow ARM multiplatform configurations
to build for omap2+. This can now be done as this file now only
contains platform_data.

cc: Russell King <linux@arm.linux.org.uk>
cc: Alan Cox <alan@linux.intel.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Govindraj.R <govindraj.raja@ti.com>
cc: Kevin Hilman <khilman@ti.com>
cc: linux-serial@vger.kernel.org
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

CONFIG_HOTPLUG is going away as an option so __devexit is no
longer needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Cc: Lucas Tavares <lucaskt@linux.vnet.ibm.com>
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Tony Prisk <linux@prisktech.co.nz>
Acked-by: NDavid Brown <davidb@codeaurora.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Lucas Tavares <lucaskt@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Tony Prisk <linux@prisktech.co.nz>
Acked-by: NTobias Klauser <tklauser@distanz.ch>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>