1. 23 2月, 2012 1 次提交
  2. 27 1月, 2012 3 次提交
  3. 25 1月, 2012 9 次提交
    • 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
    • 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
  4. 05 1月, 2012 9 次提交
  5. 04 1月, 2012 1 次提交
  6. 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
  7. 23 12月, 2011 9 次提交
  8. 17 12月, 2011 3 次提交
  9. 16 12月, 2011 1 次提交
    • B
      tty/serial/pmac_zilog: Fix suspend & resume · a79dd5ae
      Benjamin Herrenschmidt 提交于
      This patch reworks & simplifies pmac_zilog handling of suspend/resume,
      essentially removing all the specific code in there and using the
      generic uart helpers.
      
      This required properly registering the tty as a child of the macio (or platform)
      device, so I had to delay the registration a bit (we used to register the ports
      very very early). We still register the kernel console early though.
      
      I removed a couple of unused or useless flags as well, relying on the
      core to not call us when asleep. I also removed the essentially useless
      interrupt mutex, simplifying the locking a bit.
      
      I removed some code for handling unexpected interrupt which should never
      be hit and could potentially be harmful (causing us to access a register
      on a powered off SCC). We diable port interrupts on close always so there
      should be no need to drain data on a closed port.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a79dd5ae
  10. 15 12月, 2011 2 次提交
    • G
      ARM: OMAP2+: UART: Fix compilation/sparse warnings · da274686
      Govindraj.R 提交于
      Fixes below compilation warning.
      
      drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
      drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]
      
      Fix below sparse warning.
      
      drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in argument 2 (different signedness)
      drivers/tty/serial/omap-serial.c:392:52:    expected int *status
      drivers/tty/serial/omap-serial.c:392:52:    got unsigned int *<noident>
      Reported-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      da274686
    • G
      ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos · 2fd14964
      Govindraj.R 提交于
      Omap_uart_can_sleep function blocks system wide low power state until
      uart is active remove this func and add qos requests to prevent
      MPU from transitioning.
      
      Keep qos request to default value which will allow MPU to transition
      and while uart baud rate is available calculate the latency value
      from the baudrate and use the same to hold constraint while uart clocks
      are enabled, and if uart is auto-idled the constraint is updated with
      default constraint value allowing MPU to transition.
      
      Qos requests are blocking notifier calls so put these requests to
      work queue, also the driver uses irq_safe version of runtime API's
      and callbacks can be called in interrupt disabled context.
      So to avoid warn on slow path warning while using qos update
      API's from runtime callbacks use the qos_work_queue.
      
      During bootup the runtime_resume call backs might not be called and runtime
      callback gets called only after uart is idled by setting the autosuspend
      timeout. So qos_request from runtime resume callback might not activated during
      boot if uart baudrate is calculated during bootup for console uart, so schedule
      the qos_work queue once we calc_latency while configuring the uart port.
      
      Flush and complete any pending qos jobs in work queue while suspending.
      Signed-off-by: NGovindraj.R <govindraj.raja@ti.com>
      Acked-by: Greg Kroah-Hartman <gregkh@suse.de> (for drivers/tty changes)
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      2fd14964