Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 09 3月, 2012 2 次提交
  3. 10 2月, 2012 3 次提交
    • P
      tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds · 19723452
      由 Paul Walmsley 提交于 
      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: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19723452
    • P
      tty: serial: OMAP: block idle while the UART is transferring data in PIO mode · be4b0281
      由 Paul Walmsley 提交于 
      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 <khilman@ti.com> for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NGovindraj.R <govindraj.raja@ti.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be4b0281
    • P
      tty: serial: OMAP: use a 1-byte RX FIFO threshold in PIO mode · 0ba5f668
      由 Paul Walmsley 提交于 
      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 <linux@arm.linux.org.uk> for some
additional information on the standard behavior of the RX timeout
event, which was used to improve this commit description.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0ba5f668
  5. 09 2月, 2012 1 次提交
  7. 04 2月, 2012 2 次提交
  9. 03 2月, 2012 3 次提交
  11. 27 1月, 2012 3 次提交
  13. 25 1月, 2012 10 次提交
    • S
      serial: Fix wakeup init logic to speed up startup · 77359835
      由 Simon Glass 提交于 
      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: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      77359835
    • R
      serial: amba-pl011: lock console writes against interrupts · ef605fdb
      由 Rabin Vincent 提交于 
      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 <stable@vger.kernel.org>
Signed-off-by: NRabin Vincent <rabin.vincent@stericsson.com>
Reviewed-by: NSrinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Reviewed-by: NBibek Basu <bibek.basu@stericsson.com>
Reviewed-by: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ef605fdb
    • S
      amba-pl011: do not disable RTS during shutdown · d8d8ffa4
      由 Shreshtha Kumar Sahu 提交于 
      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: NShreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d8d8ffa4
    • P
      tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip · 43cf7c0b
      由 Paul Walmsley 提交于 
      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: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      43cf7c0b
    • P
      tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA mode · 0a697b22
      由 Paul Walmsley 提交于 
      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: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0a697b22
    • S
      omap-serial: make serial_omap_restore_context depend on CONFIG_PM_RUNTIME · b5148856
      由 Shubhrajyoti D 提交于 
      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: NGovindraj.R <govindraj.raja@ti.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b5148856
    • S
      omap-serial :Make the suspend/resume functions depend on CONFIG_PM_SLEEP. · 3bc4f0d8
      由 Shubhrajyoti D 提交于 
          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: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3bc4f0d8
    • J
      TTY: fix UV serial console regression · 0eee50af
      由 Jiri Slaby 提交于 
      Commit 74c21077 (serial: Use block_til_ready helper) and its fixup
3f582b8c (serial: fix termios settings in open) introduced a
regression on UV systems. The serial eventually freezes while being
used. It's completely unpredictable and sometimes needs a heap of
traffic to happen first.

To reproduce this, yast installation was used as it turned out to be
pretty reliable in reproducing. Especially during installation process
where one doesn't have an SSH daemon running. And no monitor as the HW
is completely headless. So this was fun to find. Given the machine
doesn't boot on vanilla before 2.6.36 final. (And the commits above
are older.)

Unless there is some bad race in the code, the hardware seems to be
pretty broken. Otherwise pure MSR read should not cause such a bug,
or?

So to prevent the bug, revert to the old behavior. I.e. read modem
status only if we really have to -- for non-CLOCAL set serials.
Non-CLOCAL works on this hardware OK, I tried. See? I don't.

And document that shit.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Cc: stable <stable@vger.kernel.org>
References: https://lkml.org/lkml/2011/12/6/573
References: https://bugzilla.novell.com/show_bug.cgi?id=718518Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0eee50af
    • L
      jsm: Fixed EEH recovery error · 26aa38ca
      由 Lucas Kannebley Tavares 提交于 
      There was an error on the jsm driver that would cause it to be unable to
recover after a second error is detected.

At the first error, the device recovers properly:

[72521.485691] EEH: Detected PCI bus error on device 0003:02:00.0
[72521.485695] EEH: This PCI device has failed 1 times in the last hour:
...
[72532.035693] ttyn3 at MMIO 0x0 (irq = 49) is a jsm
[72532.105689] jsm: Port 3 added

However, at the second error, it cascades until EEH disables the device:

[72631.229549] Call Trace:
...
[72641.725687] jsm: Port 3 added
[72641.725695] EEH: Detected PCI bus error on device 0003:02:00.0
[72641.725698] EEH: This PCI device has failed 3 times in the last hour:

It was caused because the PCI state was not being saved after the first
restore. Therefore, at the second recovery the PCI state would not be
restored.
Signed-off-by: NLucas Kannebley Tavares <lucaskt@linux.vnet.ibm.com>
Signed-off-by: NBreno Leitao <brenohl@br.ibm.com>
Acked-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      26aa38ca
    • P
      serial: group all the 8250 related code together · 9bef3d41
      由 Paul Gortmaker 提交于 
      The drivers/tty/serial dir is already getting rather busy.
Relocate the 8250 related drivers to their own subdir to
reduce the clutter.

Note that sunsu.c is not included in this move -- it is
8250-like hardware, but it does not use any of the existing
infrastructure -- and does not depend on SERIAL_8250.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9bef3d41
  15. 13 1月, 2012 1 次提交
  17. 05 1月, 2012 10 次提交
  19. 04 1月, 2012 3 次提交
  21. 28 12月, 2011 2 次提交
    • S
      serial: mxs-auart: convert to clk_prepare/clk_unprepare · a4813770
      由 Shawn Guo 提交于 
      The patch converts mxs-auart driver to clk_prepare/clk_unprepare by
using helper functions clk_prepare_enable/clk_disable_unprepare.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Alan Cox <alan@linux.intel.com>
      a4813770
    • S
      apbuart: fix section mismatch warning · ab17da5c
      由 Sam Ravnborg 提交于 
      Fix following warnings:

WARNING: drivers/tty/serial/built-in.o(.text+0x7370): Section mismatch in reference from the function grlib_apbuart_configure() to the variable .init.data:apbuart_match
The function grlib_apbuart_configure() references
the variable __initdata apbuart_match.
This is often because grlib_apbuart_configure lacks a __initdata
annotation or the annotation of apbuart_match is wrong.

+ 3 more warnings like this.

There is no guarantee that grlib_apbuart_of_driver.of_match_table
is only used at __init time - so drop the __initdata annotation.

grlib_apbuart_configure() is only used during __init so add __init
to this method too.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Daniel Hellstrom <daniel@gaisler.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab17da5c