linux-toradex.git/drivers/tty, branch v3.3-rc2

serial: Kill off Moorestown code

2012-01-26T19:19:46+00:00

All production devices operate in the Oaktrail configuration with legacy PC
elements present and an ACPI BIOS. Continue stripping out the Moorestown
elements from the tree leaving Medfield.

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

Revert "tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode"

2012-01-26T19:15:18+00:00

This reverts commit 0a697b22252c9d7208b5fb3e9fbd124dd229f1d2 as Paul
wants to rework it.

Cc: Paul Walmsley 
Cc: Tomi Valkeinen 
Cc: Govindraj Raja 
Cc: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip"

2012-01-26T19:14:42+00:00

This reverts commit 43cf7c0bebf50d0b68aa42ae6d24cf08e3f24823 as Paul
wants to redo it.

Cc: Paul Walmsley 
Cc: Tomi Valkeinen 
Cc: Govindraj Raja 
Cc: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

serial: Fix wakeup init logic to speed up startup

2012-01-25T00:29:40+00:00

The synchronize_rcu() call resulting from making every serial driver
wake-up capable (commit b3b708fa) slows boot down on my Tegra2x system
(with CONFIG_PREEMPT disabled).

But this is avoidable since it is the device_set_wakeup_enable() and then
subsequence disable which causes the delay. We might as well just make
the device wakeup capable but not actually enable it for wakeup until
needed.

Effectively the current code does this:

	device_set_wakeup_capable(dev, 1);
	device_set_wakeup_enable(dev, 1);
	device_set_wakeup_enable(dev, 0);

We can just drop the last two lines.

Before this change my boot log says:
[    0.227062] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.702928] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra

after:
[    0.227264] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.227983] serial8250.0: ttyS0 at MMIO 0x70006040 (irq = 69) is a Tegra

for saving of 450ms.

Suggested-by: Rafael J. Wysocki 
Acked-by: Rafael J. Wysocki 
Signed-off-by: Simon Glass 
Signed-off-by: Greg Kroah-Hartman

serial: amba-pl011: lock console writes against interrupts

2012-01-25T00:09:55+00:00

Protect against pl011_console_write() and the interrupt for
the console UART running concurrently on different CPUs.

Otherwise the console_write could spin for a long time
waiting for the UART to become not busy, while the other
CPU continuously services UART interrupts and keeps the
UART busy.

The checks for sysrq and oops_in_progress are taken
from 8250.c.

Cc: stable 
Signed-off-by: Rabin Vincent 
Reviewed-by: Srinidhi Kasagar 
Reviewed-by: Bibek Basu 
Reviewed-by: Shreshtha Kumar Sahu 
Signed-off-by: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

amba-pl011: do not disable RTS during shutdown

2012-01-25T00:09:55+00:00

In present driver, shutdown clears RTS and DTR in CR register. But the
documentation "Documentation/serial/driver" suggests not to disable
RTS and DTR in shutdown(). Also RTS and DTR is preserved between shutdown
and startup calls, i.e. these are restored in startup if they were enabled
while doing shutdown. So that if RTS and DTR are set using pl011_set_mctrl
then it should continue even after shutdown->startup sequence.
For throttling/unthrottling user should call pl011_set_mctrl.

Signed-off-by: Shreshtha Kumar Sahu 
Acked-by: Linus Walleij 
Acked-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip

2012-01-24T22:11:07+00:00

It seems that when the transmit FIFO threshold is reached on OMAP
UARTs, it does not result in a PRCM wakeup.  This appears to be a
silicon bug.  This means that if the MPU powerdomain is in a low-power
state, the MPU will not be awakened to refill the FIFO until the next
interrupt from another device.

The best solution, at least for the short term, would be for the OMAP
serial driver to call a OMAP subarchitecture function to prevent the
MPU powerdomain from entering a low power state while the FIFO has
data to transmit.  However, we no longer have a clean way to do this,
since patches that add platform_data function pointers have been
deprecated by the OMAP maintainer.  So we attempt to work around this
as well.  The workarounds depend on the setting of CONFIG_CPU_IDLE.

When CONFIG_CPU_IDLE=n, the driver will now only transmit one byte at
a time.  This causes the transmit FIFO threshold interrupt to stay
active until there is no more data to be sent.  Thus, the MPU
powerdomain stays on during transmits.  Aside from that energy
consumption penalty, each transmitted byte results in a huge number of
UART interrupts -- about five per byte.  This wastes CPU time and is
quite inefficient, but is probably the most expedient workaround in
this case.

When CONFIG_CPU_IDLE=y, there is a slightly more direct workaround:
the PM QoS constraint can be abused to keep the MPU powerdomain on.
This results in a normal number of interrupts, but, similar to the
above workaround, wastes power by preventing the MPU from entering
WFI.

Future patches are planned for the 3.4 merge window to implement more
efficient, but also more disruptive, workarounds to these problems.

DMA operation is unaffected by this patch.

Signed-off-by: Paul Walmsley 
Cc: Tomi Valkeinen 
Cc: Govindraj Raja 
Cc: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode

2012-01-24T22:11:07+00:00

Ensure FIFO levels are set correctly in non-DMA mode (the default).
This patch will cause a receive FIFO threshold interrupt to be raised when
there is at least one byte in the RX FIFO.  It will also cause a transmit
FIFO threshold interrupt when there is only one byte remaining in the TX
FIFO.

These changes fix the receive interrupt problem and part of the
transmit interrupt problem.  A separate set of issues must be worked
around for the transmit path to have a basic level of functionality; a
subsequent patch will address these.

DMA operation is unaffected by this patch.

Signed-off-by: Paul Walmsley 
Cc: Tomi Valkeinen 
Cc: Govindraj Raja 
Cc: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME

2012-01-24T22:11:06+00:00

The function serial_omap_restore_context is called only from
serial_omap_runtime_resume which depends on CONFIG_PM_RUNTIME. Make
serial_omap_restore_context also compile conditionally.

if CONFIG_PM_RUNTIME is not defined below warn may be seen.

  LD      net/xfrm/built-in.o
drivers/tty/serial/omap-serial.c:1524: warning: 'serial_omap_restore_context' defined but not used
  CC      drivers/tty/vt/selection.o

Acked-by: Govindraj.R 
Signed-off-by: Shubhrajyoti D 
Signed-off-by: Greg Kroah-Hartman

omap-serial :Make the suspend/resume functions depend on CONFIG_PM_SLEEP.

2012-01-24T22:11:05+00:00

    The macro SET_SYSTEM_SLEEP_PM_OPS  depends CONFIG_PM_SLEEP. The patch
    defines the suspend and resume functions for CONFIG_PM_SLEEP instead of
    CONFIG_SUSPEND.

Signed-off-by: Shubhrajyoti D 
Signed-off-by: Greg Kroah-Hartman