linux/drivers/tty, branch v3.3

sh-sci / PM: Avoid deadlocking runtime PM

2012-03-09T03:59:44Z

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: Rafael J. Wysocki Tested-by: Kuninori Morimoto Signed-off-by: Paul Mundt

tty/powerpc: early udbg consoles can't be modules

2012-02-25T00:11:50Z

Fixes these build errors: ERROR: ".udbg_printf" [drivers/tty/ehv_bytechan.ko] undefined! ERROR: ".register_early_udbg_console" [drivers/tty/ehv_bytechan.ko] undefined! ERROR: "udbg_putc" [drivers/tty/ehv_bytechan.ko] undefined! Cc: Timur Tabi Signed-off-by: Stephen Rothwell Cc: stable Signed-off-by: Greg Kroah-Hartman

tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds

2012-02-09T18:48:36Z

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: Paul Walmsley Cc: Tomi Valkeinen Cc: Alan Cox Acked-by: Govindraj.R Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman

tty: serial: OMAP: block idle while the UART is transferring data in PIO mode

2012-02-09T18:48:34Z

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 for mentioning the erratum i291 workaround, which led to the development of this approach. Signed-off-by: Paul Walmsley Cc: Alan Cox Cc: Tomi Valkeinen Acked-by: Govindraj.R Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman

tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode

2012-02-09T18:48:32Z

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 for some additional information on the standard behavior of the RX timeout event, which was used to improve this commit description. Signed-off-by: Paul Walmsley Cc: Tomi Valkeinen Cc: Govindraj Raja Cc: Alan Cox Cc: Russell King Reviewed-by: Kevin Hilman Tested-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman

m32r: relocate drivers back out of 8250 dir

2012-02-08T23:04:32Z

Commit 9bef3d4197379a995fa80f81950bbbf8d32e9e8b "serial: group all the 8250 related code together" inadvertently swept up the m32r driver in the move, because it had comments mentioning 8250 registers within it. However these are only there by nature of the driver being based off the 8250 source code -- the hardware itself does not actually have any relation to the original 8250 style UARTs. Reported-by: Jiri Slaby Signed-off-by: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman

tty: fix a build failure on sparc

2012-02-03T19:26:07Z

On sparc, there is a build failure: drivers/tty/serial/8250/8250.c:48:21: error: suncore.h: No such file or directory drivers/tty/serial/8250/8250.c:3275: error: implicit declaration of function 'sunserial_register_minors' drivers/tty/serial/8250/8250.c:3305: error: implicit declaration of function 'sunserial_unregister_minors' this is due to commit 9bef3d4197379a995fa80f81950bbbf8d32e9e8b (serial: group all the 8250 related code together) moved these files into 8250/ subdirectory, but forgot to change the reference to drivers/tty/serial/suncore.h. Cc: Paul Gortmaker Signed-off-by: WANG Cong Signed-off-by: Greg Kroah-Hartman

serial: samsung: Add support for EXYNOS5250

2012-02-03T00:11:24Z

Cc: Thomas Abraham Cc: Greg Kroah-Hartman Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman

serial: samsung: Add support for EXYNOS4212 and EXYNOS4412

2012-02-03T00:11:24Z

This should be added for EXYNOS4212 and EXYNOS4412 SoCs. Cc: Thomas Abraham Cc: Greg Kroah-Hartman Cc: stable Signed-off-by: Kukjin Kim Signed-off-by: Greg Kroah-Hartman

drivers/tty/vt/vt_ioctl.c: fix KDFONTOP 32bit compatibility layer

2012-02-03T00:11:23Z

KDFONTOP(GET) currently fails with EIO when being run in a 32bit userland with a 64bit kernel if the font width is not 8. This is because the compatibility layer introduced by e9216651 ("tty: handle VT specific compat ioctls in vt driver") forces the addition of the KD_FONT_FLAG_OLD flag, which makes con_font_get return EIO in such case. This flag should *not* be set for KDFONTOP, since it's actually the whole point of this flag (see comment in con_font_set for instance). Signed-off-by: Samuel Thibault Cc: Arnd Bergmann Cc: Arthur Taylor Cc: Jiri Slaby Cc: Jiri Olsa Cc: stable Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman