The driver checks if the interrupt number is greater than nr_irqs and
returns an error in that case. The same check is already performed by
the caller, remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Rewrite the baud rate register value calculations in easier to read
forms. The computed value isn't modified.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The algorithm isn't used, remove it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

This helps locating duplicates.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

The break timer accesses hardware registers and thus requires the port
to be enabled. It currently ensures this by enabling the port at the
beginning of the timer handler, and disabling it at the end. However,
the enable/disable operations call the runtime PM sync functions, which
are not allowed in atomic context. The current situation is thus broken.

This change relies on non-atomic code to enable/disable the port. The
break timer will only be started from the IRQ handler, which already
runs with the port enabled. We just need to ensure that the port won't
be disabled with the timer running, and that's easily done by just
cancelling the timer in the port disable function.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NMagnus Damm <damm@opensource.se>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Use the %zu and %pad printk specifiers to print size_t and dma_addr_t
variables, and cast pointers to uintptr_t instead of unsigned int where
applicable. This fixes warnings on platforms where pointers and/or
dma_addr_t have a different size than int.

Cc: linux-serial@vger.kernel.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

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>

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>

This change addresses two warnings that are flagged by gcc relating to
potential access to the ssr and cks variables while they are uninitialised.

I have addressed this by initialising the values to
the defaults present in sci_baud_calc_hscif().

It is my analysis that cks is always initialised if used
but that without this change ssr may be accessed while uninitialised.

The code altered by this patch was introduced by commit
f303b364 ("serial: sh-sci: HSCIF support").
Reported-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Adds support for "High Speed Serial Communications Interface with FIFO",
essentially a SCIF with 128-byte FIFOs and more accurate baud rate
generator.
Signed-off-by: NUlrich Hecht <ulrich.hecht@gmail.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

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>

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.

tty_insert_flip_char is the next one to proceed. This one is used all
over the code, so the patch is huge.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
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 pointer in
many call sites. Only tty_port will be needed and hence no more
tty_port_tty_get calls in those paths.

Here we start with tty_buffer_request_room.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
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>

In the previous commit, console write function (serial_console_write)
is changed to disable SCI interrupts while printing console strings.
This introduces possible race cases in the serial startup / shutdown
functions on SMP systems.

This patch fixes the sh-sci in the same way as commit 9ec1882d
(tty: serial: imx: console write routing is unsafe on SMP, from
Xinyu Chen <xinyu.chen@freescale.com>, 2012-08-27) did.

There could be several consumers of the console,
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which opens /dev/console and writes with sys_write()

The shell goes into the normal UART open() and write() system calls,
while the other two go into the console operations.  The open() call
invokes serial startup function (sci_startup), which will write to
the SCSCR register (to enable or disable SCI interrupts) without any
locking.  This will conflict with the console serial function.

Add spinlock protections in sci_startup() and sci_shutdown() properly.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Symptom:

When entering the suspend with Android logcat running, printk() call
gets stuck and never returns.  The issue can be observed at printk()s
on nonboot CPUs when going to offline with their interrupts disabled,
and never seen at boot CPU (core0 in our case).

Details:

serial_console_write() lacks of appropriate spinlock handling.

In SMP systems, as long as sci_transmit_chars() is being processed
at one CPU core, serial_console_write() can stuck at the other CPU
core(s), when it tries to access to the same serial port _without_
a proper locking.  serial_console_write() waits for the transmit FIFO
getting empty, while sci_transmit_chars() writes data to the FIFO.

In general, peripheral interrupts are routed to boot CPU (core0) by
Linux ARM standard affinity settings.  SCI(F) interrupts are handled
by core0, so sci_transmit_chars() is processed on core0 as well.

When logcat is running, it writes enormous log data to the kernel at
every moment, forever.  So core0 can repeatedly continue to process
sci_transmit_chars() in its interrupt handler, which eventually makes
the other CPU core(s) stuck at serial_console_write().

Looking at serial/8250.c, this is a known console write lockup issue
with SMP kernels.  Fix the sh-sci driver in the same way 8250.c does.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

About FIFO count, there are two variants of SCIFs which show
a) TX count in upper, RX count in lower byte of FDR register
b) TX count in TFDR register, RX count in RFDR register

Common SCIFB regmap in current source code is defined as "a".
At least 7372 and 73a0 HW manual say their SICFB are "b".

This patch alters the definition to "b", considering the current
one has come from a mistake. The reason is as follows.

The flag SCIFB sh-sci driver means it has 256 byte FIFO.
The count is from 0(empty) to 256(full), that makes 9-bit.
Because FDR is 16-bit register, it can not hold two 9-bits.
That's why, SCIFB can not be "a".
Signed-off-by: NTakashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Current mask 0xff to SCTFDR/RFDR damages SCIFB, because the
registers on SCIFB have 9-bit data (0 to 256).

This patch changes the mask according to port->fifosize.
Though I'm not sure if the mask is really needed (I don't know if
there are variants which have non-zero upper bits), it is safer.
Signed-off-by: NTakashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Support prescaler 1/16 and 1/64, in addition to current 1 and 1/4.

Supporting below 2400bps was dropped long time ago in mainline.
Since then, setting lower rate has been resulting in erroneous
register value, without indicating any errors through API.

This patch adds more prescaler to support lower rates again.
This still doesn't check range, but we won't hit the case because
even 50bps at 48MHz clock is now supported.
Signed-off-by: NTakashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

SCBRR == 0 is valid value (divide by 1).
Signed-off-by: NTakashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The commit 1ba76220 (serial: sh-sci: console Runtime PM support,
from Magnus Damm <damm@opensource.se>, 2011-08-03), tried to support
console runtime PM, but unfortunately it didn't work for us for some
reason.  We did not investigated further at that time, instead would
like to propose a different approach.

In Linux tty/serial world, to get console PM work properly, a serial
client driver does not have to maintain .runtime_suspend()/..resume()
calls itself, but can leave console power power management handling to
the serial core driver.

This patch moves the sh-sci driver in that direction.

Notes:

* There is room to optimize console runtime PM more aggressively by
  maintaining additional local runtime PM calls, but as a first step
  having .pm() operation would suffice.

* We still have a couple of direct calls to sci_port_enable/..disable
  left in the driver.  We have to live with them, because they're out
  of serial core's help.
Signed-off-by: NTeppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This partially reverts commit 1ba76220 (serial: sh-sci: console
Runtime PM support, from Magnus Damm <damm@opensource.se>, 2011-08-03).

The generic 'serial_core' can take care of console PM maintenance,
so all (or at least the first thing) we have to do to get console PM
work properly, is to implement uart_ops ->pm() operation in the sh-sci
serial client driver.

This patch partially reverts the commit above, but leaving sci_reset()
change in place, because sci_reset() is already part of another commit
(73c3d53f serial: sh-sci: Avoid FIFO clear for MCE toggle.).

A revised version of console PM support follows next.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 5a50a01b (sh-sci / PM: Use power.irq_safe, from
Rafael J. Wysocki <rjw@sisk.pl>, 2011-08-24).

In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 048be431 (sh-sci / PM: Avoid deadlocking runtime
PM, from Rafael J. Wysocki <rjw@sisk.pl>, 2012-03-09).

In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It was already pointed out how to fix these cases before the offending
patches were merged, but unsurprisingly, that didn't happen. As this
change is entirely superfluous to begin with, simply shut things up by
casting everything away.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

A recent commit:

commit d6fa5a4e
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    serial: sh-sci: prepare for conversion to the shdma base library

is not sufficient to update the sh-sci driver to the new shdma driver
layout. This caused compilation breakage, when CONFIG_SERIAL_SH_SCI_DMA
is enabled. This patch trivially fixes the problem by updating the DMA
descriptor manipulation code.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

The driver supports a maximum number of ports configurable at compile
time. Make sure the probe() method fails when registering a port that
exceeds the maximum instead of returning success without registering the
port.

This fixes a crash at system suspend time, when the driver tried to
suspend a non-registered port using the UART core.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

When probing fails, the driver must not try to cleanup resources that
have not been initialized. Fix this.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The driver supports a maximum number of ports configurable at compile
time. Make sure the probe() method fails when registering a port that
exceeds the maximum instead of returning success without registering the
port.

This fixes a crash at system suspend time, when the driver tried to
suspend a non-registered port using the UART core.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When probing fails, the driver must not try to cleanup resources that
have not been initialized. Fix this.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In doing the evt2irq() + muxed vector conversion for various port types
it became apparent that some of the legacy port types will presently
error out due to the irq requesting logic attempting to acquire the
non-existent BRI IRQ. This adds some sanity checks to the request/free
path to ensure that non-existence of a source in itself is not an error.

This should restore functionality for legacy PORT_SCI ports.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This updates the earlier break_ctl support regardless of regtype so long
as the requisite SCSPTR exists. This is the same approach used by
sci_init_pins() for providing a generic solution now that we're able to
detect register capabilities on a per-port basis.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

SCIF modules which have SCSPTR can output the break signal. Now that we
have a way of determining port features/capabilities, add trivial break
control via SCSPTR support. Tested on sh7757lcr.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Follows the 8250 change for pretty much the same rationale.

See commit "serial: use serial_port_in/out vs serial_in/out in 8250".
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

When DMA is enabled, sh-sci transfer begins with
 uart_start()
  sci_start_tx()
    if (cookie_tx < 0) schedule_work()
Then, starts DMA when wq scheduled, -- (A)
 process_one_work()
  work_fn_rx()
   cookie_tx = desc->submit_tx()
And finishes when DMA transfer ends, -- (B)
 sci_dma_tx_complete()
  async_tx_ack()
  cookie_tx = -EINVAL
  (possible another schedule_work())

This A to B sequence is not reentrant, since controlling variables
(for example, cookie_tx above) are not queues nor lists. So, they
must be invoked as A B A B..., otherwise results in kernel crash.

To ensure the sequence, sci_start_tx() seems to test if cookie_tx < 0
(represents "not used") to call schedule_work().
But cookie_tx will not be set (to a cookie, also means "used") until
in the middle of work queue scheduled function work_fn_tx().

This gap between the test and set allows the breakage of the sequence
under the very frequently call of uart_start().
Another gap between async_tx_ack() and another schedule_work() results
in the same issue, too.

This patch introduces a new condition "cookie_tx == 0" just to mark
it is "busy" and assign it within spin-locked region to fill the gaps.
Signed-off-by: NTakashi Yoshii <takashi.yoshii.zj@renesas.com>
Reviewed-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: stable@vger.kernel.org
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Add inline wrappers for device_prep_slave_sg() and device_prep_dma_cyclic()
interfaces to hide new parameter from current users of affected interfaces.
Convert current users to use new wrappers instead of direct calls.
Suggested by Russell King [https://lkml.org/lkml/2012/2/3/269].
Signed-off-by: NAlexandre Bounine <alexandre.bounine@idt.com>
Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>

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>