1. 07 10月, 2019 1 次提交
  2. 04 9月, 2019 1 次提交
    • T
      serial: 8250_omap: Fix idling for unloaded serdev drivers · 627a545c
      Tony Lindgren 提交于
      For many years omap variants have been setting the runtime PM
      autosuspend delay to -1 to prevent unsafe policy with lossy first
      character on wake-up. The user must specifically enable the timeout
      for UARTs if desired.
      
      We must not enable the workaround for serdev devices though. It leads
      into UARTs not idling if no serdev devices are loaded and there is no
      sysfs entry to configure the UART in that case. And this means that
      my PM may not work unless the serdev modules are loaded.
      
      We can detect a serdev device being configured based on a dts child
      node, and we can simply skip the workround in that case. And the
      serdev driver can idle the port during runtime when suitable if an
      out-of-band wake-up GPIO line exists for example.
      
      Let's also add some comments to the workaround while at it.
      
      Cc: Johan Hovold <johan@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Link: https://lore.kernel.org/r/20190723115400.46432-1-tony@atomide.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      627a545c
  3. 21 6月, 2019 1 次提交
  4. 18 6月, 2019 1 次提交
  5. 18 1月, 2019 2 次提交
  6. 10 11月, 2018 1 次提交
  7. 28 6月, 2018 1 次提交
  8. 14 5月, 2018 1 次提交
    • T
      serial: 8250: omap: Fix idling of clocks for unused uarts · 13dc04d0
      Tony Lindgren 提交于
      I noticed that unused UARTs won't necessarily idle properly always
      unless at least one byte tx transfer is done first.
      
      After some debugging I narrowed down the problem to the scr register
      dma configuration bits that need to be set before softreset for the
      clocks to idle. Unless we do this, the module clkctrl idlest bits
      may be set to 1 instead of 3 meaning the clock will never idle and
      is blocking deeper idle states for the whole domain.
      
      This might be related to the configuration done by the bootloader
      or kexec booting where certain configurations cause the 8250 or
      the clkctrl clock to jam in a way where setting of the scr bits
      and reset is needed to clear it. I've tried diffing the 8250
      registers for the various modes, but did not see anything specific.
      So far I've only seen this on omap4 but I'm suspecting this might
      also happen on the other clkctrl using SoCs considering they
      already have a quirk enabled for UART_ERRATA_CLOCK_DISABLE.
      
      Let's fix the issue by configuring scr before reset for basic dma
      even if we don't use it. The scr register will be reset when we do
      softreset few lines after, and we restore scr on resume. We should
      do this for all the SoCs with UART_ERRATA_CLOCK_DISABLE quirk flag
      set since the ones with UART_ERRATA_CLOCK_DISABLE are all based
      using clkctrl similar to omap4.
      
      Looks like both OMAP_UART_SCR_DMAMODE_1 | OMAP_UART_SCR_DMAMODE_CTL
      bits are needed for the clkctrl to idle after a softreset.
      
      And we need to add omap4 to also use the UART_ERRATA_CLOCK_DISABLE
      for the related workaround to be enabled. This same compatible
      value will also be used for omap5.
      
      Fixes: cdb929e4 ("serial: 8250_omap: workaround errata around idling UART after using DMA")
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Matthijs van Duin <matthijsvanduin@gmail.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13dc04d0
  9. 23 4月, 2018 1 次提交
    • V
      serial: 8250: omap: Provide ability to enable/disable UART as wakeup source · 09d8b2bd
      Vignesh R 提交于
      Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
      return value of device_may_wakeup() in .suspend(). This allows
      userspace to use sysfs to control the ability of UART to wakeup the
      system from deep sleep state. Register is restored back in .startup()
      call that happens as part of resume sequence.
      
      With this patch, userspace can control UART wakeup capability via sysfs:
      To enable wakeup capability:
      echo enabled >  /sys/class/tty/ttyXX/device/power/wakeup
      For disabling wakeup capability:
      echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
      
      Note that the UART wakeup events configured in the 8250 hardware only
      work for idle modes that do not cut off power for the UART. For deeper
      idle states, dedicated padconf wakeirqs must be used. Or in some cases
      the UART RX pin can be remuxed to GPIO input if the GPIO block stays
      powered.
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Tested-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09d8b2bd
  10. 28 2月, 2018 1 次提交
    • V
      serial: 8250: 8250_omap: Fix throttling when DMA is enabled · 08fb00c6
      Vignesh R 提交于
      omap_8250_throttle() is called when tty RX buffer is about to overflow
      and can no longer keep up with the rate at which UART is receiving data.
      So, the expectation of this callback, is that UART stops RX and asserts
      HW flow control to signal the sender to stop sending more data.
      omap_8250_throttle() disables RX FIFO interrupts thus FIFO is no longer
      serviced, leading to assertion of flow control once RX FIFO is full.
      But, this does not work when DMA is enabled as driver keeps queuing new
      RX DMA request in completion handler without brothering about throttling
      request made by the higher layer.
      This patch introduces a flag that can be used to determine whether or
      not to queue next RX DMA request based on throttling request.
      
      Without this patch, tty buffer overflows are reported at higher
      baudrates.
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      08fb00c6
  11. 16 12月, 2017 1 次提交
  12. 08 11月, 2017 1 次提交
    • G
      tty: add SPDX identifiers to all remaining files in drivers/tty/ · e3b3d0f5
      Greg Kroah-Hartman 提交于
      It's good to have SPDX identifiers in all files to make it easier to
      audit the kernel tree for correct licenses.
      
      Update the drivers/tty files files with the correct SPDX license
      identifier based on the license text in the file itself.  The SPDX
      identifier is a legally binding shorthand, which can be used instead of
      the full boiler plate text.
      
      This work is based on a script and data from Thomas Gleixner, Philippe
      Ombredanne, and Kate Stewart.
      
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: David Sterba <dsterba@suse.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Stefan Wahren <stefan.wahren@i2se.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Ray Jui <rjui@broadcom.com>
      Cc: Scott Branden <sbranden@broadcom.com>
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Joachim Eastwood <manabian@gmail.com>
      Cc: Matthias Brugger <matthias.bgg@gmail.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Tobias Klauser <tklauser@distanz.ch>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Richard Genoud <richard.genoud@gmail.com>
      Cc: Alexander Shiyan <shc_work@mail.ru>
      Cc: Baruch Siach <baruch@tkos.co.il>
      Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
      Cc: "Uwe Kleine-König" <kernel@pengutronix.de>
      Cc: Pat Gefre <pfg@sgi.com>
      Cc: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Vladimir Zapolskiy <vz@mleia.com>
      Cc: Sylvain Lemieux <slemieux.tyco@gmail.com>
      Cc: Carlo Caione <carlo@caione.org>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Liviu Dudau <liviu.dudau@arm.com>
      Cc: Sudeep Holla <sudeep.holla@arm.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Andy Gross <andy.gross@linaro.org>
      Cc: David Brown <david.brown@linaro.org>
      Cc: "Andreas Färber" <afaerber@suse.de>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Laxman Dewangan <ldewangan@nvidia.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Jonathan Hunter <jonathanh@nvidia.com>
      Cc: Barry Song <baohua@kernel.org>
      Cc: Patrice Chotard <patrice.chotard@st.com>
      Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Timur Tabi <timur@tabi.org>
      Cc: Tony Prisk <linux@prisktech.co.nz>
      Cc: Michal Simek <michal.simek@xilinx.com>
      Cc: "Sören Brinkmann" <soren.brinkmann@xilinx.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Kate Stewart <kstewart@linuxfoundation.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Jiri Slaby <jslaby@suse.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3b3d0f5
  13. 04 10月, 2017 1 次提交
  14. 29 6月, 2017 1 次提交
    • V
      serial: 8250: 8250_omap: Fix race b/w dma completion and RX timeout · a1bfb6eb
      Vignesh R 提交于
      DMA RX completion handler for UART is called from a tasklet and hence
      may be delayed depending on the system load. In meanwhile, there may be
      RX timeout interrupt which can get serviced first before DMA RX
      completion handler is executed for the completed transfer.
      omap_8250_rx_dma_flush() which is called on RX timeout interrupt makes
      sure that the DMA RX buffer is pushed and then the FIFO is drained and
      also queues a new DMA request. But, when DMA RX completion handler
      executes, it will erroneously flush the currently queued DMA transfer
      which sometimes results in data corruption and double queueing of DMA RX
      requests.
      
      Fix this by checking whether RX completion is for the currently queued
      transfer or not. And also hold port lock when in DMA completion to avoid
      race wrt RX timeout handler preempting it.
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a1bfb6eb
  15. 18 5月, 2017 1 次提交
    • V
      serial: 8250: omap: Disable DMA for console UART · 84b40e3b
      Vignesh R 提交于
      Kernel always writes log messages to console via
      serial8250_console_write()->serial8250_console_putchar() which directly
      accesses UART_TX register _without_ using DMA.
      
      But, if other processes like systemd using same UART port, then these
      writes are handled by a different code flow using 8250_omap driver where
      there is provision to use DMA.
      
      It seems that it is possible that both DMA and CPU might simultaneously
      put data to UART FIFO and lead to potential loss of data due to FIFO
      overflow and weird data corruption. This happens when both kernel
      console and userspace tries to write simultaneously to the same UART
      port. Therefore, disable DMA on kernel console port to avoid potential
      race between CPU and DMA.
      Signed-off-by: NVignesh R <vigneshr@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84b40e3b
  16. 25 1月, 2017 1 次提交
    • T
      serial: 8250_omap: Fix probe and remove for PM runtime · 4e0f5cc6
      Tony Lindgren 提交于
      Otherwise the interconnect related code implementing PM runtime will
      produce these errors on a failed probe:
      
      omap_uart 48066000.serial: omap_device: omap_device_enable() called from invalid state 1
      omap_uart 48066000.serial: use pm_runtime_put_sync_suspend() in driver?
      
      Note that we now also need to check for priv in omap8250_runtime_suspend()
      as it has not yet been registered if probe fails. And we need to use
      pm_runtime_put_sync() to properly idle the device like we already do
      in omap8250_remove().
      
      Fixes: 61929cf0 ("tty: serial: Add 8250-core based omap driver")
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e0f5cc6
  17. 20 1月, 2017 3 次提交
  18. 31 8月, 2016 1 次提交
  19. 26 6月, 2016 2 次提交
  20. 01 5月, 2016 6 次提交
  21. 08 3月, 2016 1 次提交
  22. 07 2月, 2016 1 次提交
  23. 18 10月, 2015 1 次提交
  24. 05 10月, 2015 1 次提交
  25. 15 8月, 2015 1 次提交
  26. 24 7月, 2015 6 次提交