1. 21 10月, 2016 1 次提交
  2. 08 7月, 2016 1 次提交
    • F
      spi: omap2-mcspi: Use the SPI framework to handle DMA mapping · 0ba1870f
      Franklin S Cooper Jr 提交于
      Currently, the driver handles mapping buffers to be used by the DMA.
      However, there are times that the current mapping implementation will
      fail for certain buffers. Fortunately, the SPI framework can detect
      and map buffers so its usable by the DMA.
      
      Update the driver to utilize the SPI framework for buffer
      mapping instead. Also incorporate hooks that the framework uses to
      determine if the DMA can or can not be used.
      
      This will result in the original omap2_mcspi_transfer_one function being
      deleted and omap2_mcspi_work_one being renamed to
      omap2_mcspi_transfer_one. Previously transfer_one was only responsible
      for mapping and work_one handled the transfer. But now only transferring
      needs to be handled by the driver.
      Signed-off-by: NFranklin S Cooper Jr <fcooper@ti.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      0ba1870f
  3. 05 7月, 2016 1 次提交
  4. 30 4月, 2016 1 次提交
  5. 12 4月, 2016 1 次提交
  6. 23 3月, 2016 1 次提交
  7. 13 2月, 2016 1 次提交
    • T
      spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit · 0e6f357a
      Tony Lindgren 提交于
      Commit 5de85b9d ("PM / runtime: Re-init runtime PM states at probe
      error and driver unbind") introduced pm_runtime_reinit() that is used
      to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
      down the device after a failed probe.
      
      However, for drivers using pm_runtime_use_autosuspend() this can cause
      a state where suspend callback is never called after -EPROBE_DEFER.
      On the following device driver probe, hardware state is different from
      the PM runtime state causing omap_device to produce the following
      error:
      
      omap_device_enable() called from invalid state 1
      
      And with omap_device and omap hardware being picky for PM, this will
      block any deeper idle states in hardware.
      
      The solution is to fix the drivers to follow the PM runtime documentation:
      
      1. For sections of code that needs the device disabled, use
         pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
         been set.
      
      2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
         pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
         set.
      
      Fixes: 5de85b9d ("PM / runtime: Re-init runtime PM states at probe
      error and driver unbind")
      Cc: linux-spi@vger.kernel.org
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Nishanth Menon <nm@ti.com>
      Cc: Rafael J. Wysocki <rafael@kernel.org>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Tero Kristo <t-kristo@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      0e6f357a
  8. 02 12月, 2015 1 次提交
  9. 20 11月, 2015 1 次提交
  10. 22 10月, 2015 1 次提交
    • N
      spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message · 468a3208
      Neil Armstrong 提交于
      Since the "Switch driver to use transfer_one" change, the cs_change
      behavior has changed and a channel chip select can still be
      asserted when changing channel from a previous last transfer in a
      message having the cs_change attribute.
      
      Since there is no sense having multiple chip select being asserted at the
      same time, disable all the remaining forced chip selects in a the
      prepare_message called right before a spi_transfer_one_message call.
      It ignores the current channel configuration in order to keep the
      possibility to leave the chip select asserted between messages.
      
      It fixes this bug on a DM8168 SoC ES2.1 Soc and an OMAP4 ES2.1 SoC.
      It was hanging all the other channels transfers when a CHCONF_FORCE
      is present on the wrong channel.
      
      Fixes: b28cb941 ("spi: omap2-mcspi: Switch driver to use transfer_one")
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Reviewed-by: NMichael Welling <mwelling@ieee.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      468a3208
  11. 25 7月, 2015 1 次提交
  12. 25 5月, 2015 4 次提交
  13. 13 5月, 2015 1 次提交
  14. 09 5月, 2015 1 次提交
  15. 08 5月, 2015 1 次提交
  16. 24 4月, 2015 1 次提交
  17. 22 12月, 2014 1 次提交
  18. 20 10月, 2014 1 次提交
  19. 12 8月, 2014 1 次提交
  20. 04 7月, 2014 1 次提交
    • M
      spi: omap2-mcspi: Configure hardware when slave driver changes mode · 97ca0d6c
      Mark A. Greer 提交于
      Commit id 2bd16e3e
      (spi: omap2-mcspi: Do not configure the controller
      on each transfer unless needed) does its job too
      well so omap2_mcspi_setup_transfer() isn't called
      even when an SPI slave driver changes 'spi->mode'.
      The result is that the mode requested by the SPI
      slave driver never takes effect.
      
      Fix this by adding the 'mode' member to the
      omap2_mcspi_cs structure which holds the mode
      value that the hardware is configured for.
      When the SPI slave driver changes 'spi->mode'
      it will be different than the value of this new
      member and the SPI master driver will know that
      the hardware must be reconfigured (by calling
      omap2_mcspi_setup_transfer()).
      
      Fixes: 2bd16e3e (spi: omap2-mcspi: Do not configure the controller on each transfer unless needed)
      Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Cc: stable@vger.kernel.org
      97ca0d6c
  21. 03 4月, 2014 1 次提交
  22. 19 2月, 2014 2 次提交
  23. 04 2月, 2014 2 次提交
  24. 03 2月, 2014 1 次提交
  25. 24 11月, 2013 1 次提交
  26. 17 10月, 2013 1 次提交
  27. 10 10月, 2013 1 次提交
  28. 26 9月, 2013 1 次提交
  29. 29 8月, 2013 1 次提交
  30. 30 7月, 2013 1 次提交
  31. 24 6月, 2013 1 次提交
  32. 18 6月, 2013 1 次提交
    • I
      spi: omap2-mcspi: Add FIFO buffer support · d33f473d
      Illia Smyrnov 提交于
      The MCSPI controller has a built-in FIFO buffer to unload the DMA or interrupt
      handler and improve data throughput. This patch adds FIFO buffer support for SPI
      transfers in DMA mode.
      
      For SPI transfers in DMA mode, the largest possible FIFO buffer size will be
      calculated and set up. The FIFO won't be used for the SPI transfers in DMA mode
      if: calculated FIFO buffer size is less then 2 bytes or the FIFO buffer size
      isn't multiple of the SPI word length.
      Signed-off-by: NIllia Smyrnov <illia.smyrnov@ti.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      d33f473d
  33. 17 6月, 2013 1 次提交
  34. 30 5月, 2013 1 次提交
  35. 23 5月, 2013 1 次提交