linux/drivers/tty/serial/sh-sci.c, branch v3.8

tty: remove use of __devinit

2012-11-21T23:22:52Z

CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton Cc: Jiri Slaby Cc: Alan Cox Cc: Lucas Tavares Cc: "David S. Miller" Cc: Peter Korsgaard Cc: Tony Prisk Acked-by: Tobias Klauser Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: fix possible race cases on SCSCR register accesses

2012-11-16T02:02:51Z

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 9ec1882df2 (tty: serial: imx: console write routing is unsafe on SMP, from Xinyu Chen , 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: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: add locking to console write function to avoid SMP lockup

2012-11-16T02:02:51Z

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: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: fix common SCIFB regmap definition

2012-11-16T02:02:51Z

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: Takashi Yoshii Signed-off-by: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: mask SCTFDR/RFDR according to fifosize

2012-11-16T02:02:37Z

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: Takashi Yoshii Signed-off-by: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: support lower baud rate

2012-11-16T02:02:37Z

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: Takashi Yoshii Signed-off-by: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: fix condition test to set SCBRR

2012-11-16T02:02:37Z

SCBRR == 0 is valid value (divide by 1). Signed-off-by: Takashi Yoshii Signed-off-by: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: console runtime PM support (revisit)

2012-11-16T02:02:36Z

The commit 1ba7622094 (serial: sh-sci: console Runtime PM support, from Magnus Damm , 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: Teppei Kamijou Signed-off-by: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

Partially revert "serial: sh-sci: console Runtime PM support"

2012-11-16T02:02:36Z

This partially reverts commit 1ba7622094 (serial: sh-sci: console Runtime PM support, from Magnus Damm , 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 (73c3d53f38 serial: sh-sci: Avoid FIFO clear for MCE toggle.). A revised version of console PM support follows next. Signed-off-by: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman

Revert "sh-sci / PM: Use power.irq_safe"

2012-11-16T02:02:04Z

This reverts commit 5a50a01bf0 (sh-sci / PM: Use power.irq_safe, from Rafael J. Wysocki , 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: Shinya Kuribayashi Signed-off-by: Greg Kroah-Hartman