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>

CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer
needed.
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
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>

When the UART device has hardware flow control enabled, it ignores the
MCR RTS bit in the MCR register, and keeps RTS asserted as long as we
continue to read characters from the UART receiver FIFO.  This means
that when the TTY buffers become full, the UART doesn't tell the remote
end to stop sending, which causes the TTY layer to start dropping
characters.

A similar problem exists with software flow control.  We need the FIFO
register to fill when software flow control is enabled to provoke the
UART to send the XOFF character.

Fix this by implementing the throttle/unthrottle callbacks, and use
these to disable receiver interrupts.  This in turn means that the UART
FIFO will fill, which will then cause the UART's hardware to deassert
the RTS signal and/or send the XOFF character, stopping the remote end.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Simplify:
	- set ECB
	...
	- LCR mode A
	- clear TCRTLR
	- LCR mode B
	- clear ECB
	- set ECB and update other bits
	- LCR mode A
	- update XONANY

to:
	- set ECB
	...
	- LCR mode B
	- set ECB and update other bits
	- LCR mode A
	- update XONANY and clear TCRTLR
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Take advantage of the switch to mode B for accessing the TCR register,
and move the xon/xoff configuration there.  This allows further
simplication of this sequence.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We always setup the TCR register in the software flow control path,
and when hardware flow control is enabled.  Remove this redundant
setup, and place it before we setup any hardware flow control.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We have the sequence:
	- LCR mode B
	- write EFR with ECB clear
	- LCR mode normal
	- if s/w flow
		- LCR mode B
		- write EFR with ECB clear
		...
		- LCR mode B
		- write EFR with ECB clear
		- LCR mode normal

This can be simplified to:
	- if s/w flow
		- LCR mode B
		- write EFR with ECB clear
		...
	- LCR mode B
	- write EFR with ECB clear
	- LCR mode normal
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There's really no reason to read back these registers while setting
the termios modes, provided we keep our cached copies up to date.
Remove these readbacks.

This has the benefit that we know that the EFR_ECB and MCR_TCRTLR
bits will always be clear, so we don't need to keep masking these
bits throughout the code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

struct uart_omap_port and struct uart_omap_dma, and associated
definitions are private to the driver, so there's no point them sitting
in an include file under arch/arm.  Move them into the driver itself.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

irq_pending is never used, so let's remove it.  It seems to be  result
of a bad rebase of d37c6ceb (serial: omap: move uart_omap_port
definition to C file)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The MCR TCRTLR bit can only be changed when ECB is set in the EFR.
Unfortunately, several places were trying to alter this bit while ECB
was clear:

- serial_omap_configure_xonxoff() was attempting to clear the bit after
  explicitly clearing the ECB bit.
- serial_omap_set_termios() was trying the same trick after setting the
  SCR, and when trying to change the TCR register when hardware flow
  control was enabled.

Fix this by ensuring that we always have ECB set whenever the TCRTLR bit
is changed.

Moreover, we start out by reading the EFR and MCR registers, which may
have indeterminent bit settings for the ECB and TCRTLR bits.  Ensure
that these bits always start off in a known state.

In order to avoid any undesired behaviour appearing through fixing this,
we also ensure that hardware assisted flow control is disabled while new
driver specific parts are not in place.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

c538d20c (and maybe previous commits) broke set_mctrl() by making
it only capable of setting bits in the MCR register.  This prevents
software controlled flow control and modem control line manipulation
via TIOCMSET/TIOCMBIC from working correctly.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There's no need to re-read EFR after we've recently written it; the
register is a configuration register which doesn't change its value
without us writing to it.  The last value which was written to this
register was up->efr.

Removing this re-reading avoids the possibility that we end up with
up->efr having unintended bits set, which should only be temporarily
set when accessing the enhanced features.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The SCD (special character detect) bit enables comparisons with XOFF2,
which we do not program.  As the XOFF2 character remains unprogrammed,
there's little point enabling this feature along with its associated
interrupt.  Remove this, and ensure that the SCD bit is cleared.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Nothing was clearing the UART_MCR_XONANY bit, so once the ixany
mode gets set, there's no possibility to disable it.  Clear this
bit when IXANY mode is cleared.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There is nothing which clears the auto RTS/CTS bits, so once hardware
flow control gets enabled, there's no possibility to disable it.
So, clear these bits when CRTSCTS is cleared.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently the array serial_omap_console_ports is hard coded to 4.
Make it depend on the maximum uart count.
Post to [cfc55bcc ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6]
the max ports is 6.

Cc: AnilKumar Ch <anilkumar@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Special character detect enable if enabled by default.Received data
comparison with XOFF2 data happens by default.

tty provides only XOFF1 no X0FF2 is provided so no need
to enable check for XOFF2.

Keeping this enabled might give some slow transfers due to dummy xoff2
comparison with xoff2 reset value.

Since not all want the XOFF2 support lets not enable it by
default.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

get_context_loss_count returns an int however it is stored in
unsigned integer context_loss_cnt . This patch tries to make
context_loss_cnt int. So that in case of errors the value
(which may be negative) is not interpreted wrongly.

In serial_omap_runtime_resume in case of errors returned by
get_context_loss_count print a warning and do a restore.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 957ee727
(serial: omap: fix software flow control).

As Russell has pointed out, that commit isn't fixing
Software Flow Control at all, and it actually makes
it even more broken.

It was agreed to revert this commit and use Russell's
latest UART patches instead.

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch does the following
- In case of errors if there least one data character in the RX FIFO
read it otherwise it may stall the receiver.

This is recommended in the interrupt reset method in the table 23-246 of
the omap4 TRM.
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Drop the check for "up" being valid on suspend/resume callbacks.
It should be valid always. Get rid of the "pdata" check also as
serial_omap_get_context_loss_count() checks for it.

Tested on omap4 panda and 3630 based Beagle board.
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Request pins using pinctrl framework. Only show a warning
on error as some boards set the pins in the bootloader
even if CONFIG_PINCTRL is enabled.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

OMAP Architecture code, passes a few function
pointers for UART driver to use in order to
properly implement Power Management and Wakeup
capabilities.

The problem is that those function pointers,
which are passed (ab)using platform_data on
non-DT kernels, can't be passed down to drivers
through DT.

commit e5b57c03 (serial: omap: define helpers
for pdata function pointers) failed to take DT
kernels into consideration and caused a regression
to DT kernel boot.

Fix that by (re-)adding a check for valid pdata
pointer together with valid pdata->$FUNCTION
pointer.
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

when rebasing patches on top of Greg's tty-next,
it looks like automerge broke a few things which
I didn't catch (for whatever reason I didn't
have OMAP Serial enabled on .config) so I ended
up breaking the build on Greg's tty-next branch.

Fix the breakage by re-adding the three missing
members on struct uart_omap_port.
Reported-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

enable RX FIFO for 16 characters and TX FIFO
for 16 spaces.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

nobody needs to access the uart_omap_port structure
other than omap-serial.c file. Let's move that
structure definition to the C source file in order
to prevent anyone from accessing our structure.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

this driver doesn't use any from <plat/dmtimer.h>, so
we can remove it without any problems.

This will, however cause a problem because omap-serial.c
was relying on indirect inclusion of <linux/platform_device.h>,
let's fix the issue by including <linux/platform_device.h>
on omap-serial.c as it should be.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Software flow control register bits were not defined correctly.

Also clarify the IXON and IXOFF logic to reflect what userspace wants.

Cc: stable@vger.kernel.org
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

if we would reach serial_omap_get_char() while
Data Ready bit isn't set, we would return from
it without kicking our pm timer. This would mean
we would, eventually, have an unbalanced
pm_runtime_get on our device which would prevent
it from ever sleeping again.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This has been missing from OMAP UART driver
for quite a while and it's simple enough
to implement it.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch unlocks the port lock before calling a serial_core API
and re-acquires the port lock after calling it.
This patch fixes a system freeze issue seen when the serial_core
API uart_write_wakeup() eventually attempts to acquire the port lock
already acquired by omap serial interrupt handler.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NRuchika Kharwar <ruchika@ti.com>
Signed-off-by: NPavan Savoy <pavan_savoy@ti.com>
Signed-off-by: NVijay Badawadagi <bvijay@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

it makes no sense to mark our IRQ handler inline
since it's passed as a function pointer when
enabling the IRQ line.
Tested-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>