1. 05 Apr, 2019 1 commit
    • Sowjanya Komatineni's avatar
      spi: tegra114: de-assert CS before SPI mode change · f3e182c3
      Sowjanya Komatineni authored
      With SW CS, during the transfer completion CS is de-asserted by writing
      default command1 register value to SPI_COMMAND1 register. With this both
      mode and CS state are set at the same time and if current transfer mode
      is different to default SPI mode and if mode change happens prior to CS
      de-assert, clock polarity can change while CS is active before transfer
      finishes.
      
      This causes Slave to see spurious clock edges resulting in data mismatch.
      
      This patch fixes this by de-asserting CS before writing SPI_COMMAND1 to
      its default value so through out the transfer it will be in same SPI mode.
      Signed-off-by: default avatarSowjanya Komatineni <skomatineni@nvidia.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      f3e182c3
  2. 04 Apr, 2019 2 commits
  3. 01 Apr, 2019 7 commits
  4. 27 Mar, 2019 1 commit
  5. 21 Mar, 2019 1 commit
  6. 18 Mar, 2019 1 commit
  7. 15 Mar, 2019 3 commits
    • Ludovic Barre's avatar
      spi: spi-mem: stm32-qspi: avoid memory corruption at low frequency · 5356c2c7
      Ludovic Barre authored
      This patch solves a memory corruption seen at 8 MHz.
      To avoid such issue, timeout counter is disabled.
      Signed-off-by: default avatarLudovic Barre <ludovic.barre@st.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      5356c2c7
    • Geert Uytterhoeven's avatar
      spi: rspi: Fix sequencer reset during initialization · 26843bb1
      Geert Uytterhoeven authored
      While the sequencer is reset after each SPI message since commit
      880c6d11 ("spi: rspi: Add support for Quad and Dual SPI
      Transfers on QSPI"), it was never reset for the first message, thus
      relying on reset state or bootloader settings.
      
      Fix this by initializing it explicitly during configuration.
      
      Fixes: 0b2182dd ("spi: add support for Renesas RSPI")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      26843bb1
    • Geert Uytterhoeven's avatar
      spi: rspi: Fix register initialization while runtime-suspended · 42bdaaec
      Geert Uytterhoeven authored
      The Renesas RSPI/QSPI driver performs SPI controller register
      initialization in its spi_operations.setup() callback, without calling
      pm_runtime_get_sync() first, which may cause spurious failures.
      
      So far this went unnoticed, as this SPI controller is typically used
      with a single SPI NOR FLASH containing the boot loader:
        1. If the device's module clock is still enabled (left enabled by the
           bootloader, and not yet disabled by the clk_disable_unused() late
           initcall), register initialization succeeds,
        2. If the device's module clock is disabled, register writes don't
           seem to cause lock-ups or crashes.
           Data received in the first SPI message may be corrupted, though.
           Subsequent SPI messages seem to be OK.
           E.g. on r8a7791/koelsch, one bit is lost while receiving the 6th
           byte of the JEDEC ID for the s25fl512s FLASH, corrupting that byte
           and all later bytes.  But until commit a2126b0a ("mtd:
           spi-nor: refine Spansion S25FL512S ID"), the 6th byte was not
           considered for FLASH identification.
      
      Fix this by moving all initialization from the .setup() to the
      .prepare_message() callback.  The latter is always called after the
      device has been runtime-resumed by the SPI core.
      
      This also makes the driver follow the rule that .setup() must not change
      global driver state or register values, as that might break a transfer
      in progress.
      
      Fixes: 490c9774 ("spi: rspi: Add runtime PM support, using spi core auto_runtime_pm")
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      42bdaaec
  8. 13 Mar, 2019 1 commit
    • Trent Piepho's avatar
      spi: imx: stop buffer overflow in RX FIFO flush · c842749e
      Trent Piepho authored
      Commit 71abd290 ("spi: imx: Add support for SPI Slave mode") added
      an RX FIFO flush before start of a transfer.  In slave mode, the master
      may have sent more data than expected and this data will still be in the
      RX FIFO at the start of the next transfer, and so needs to be flushed.
      
      However, the code to do the flush was accidentally saving this data into
      the previous transfer's RX buffer, clobbering the contents of whatever
      followed that buffer.
      
      Change it to empty the FIFO and throw away the data.  Every one of the
      RX functions for the different eCSPI versions and modes reads the RX
      FIFO data using the same readl() call, so just use that, rather than
      using the spi_imx->rx function pointer and making sure all the different
      rx functions have a working "throw away" mode.
      
      There is another issue, which affects master mode when switching from
      DMA to PIO.  There can be extra data in the RX FIFO which triggers this
      flush code, causing memory corruption in the same manner.  I don't know
      why this data is unexpectedly in the FIFO.  It's likely there is a
      different bug or erratum responsible for that.  But regardless of that,
      I think this is proper fix the for bug at hand here.
      
      Fixes: 71abd290 ("spi: imx: Add support for SPI Slave mode")
      Cc: Jiada Wang <jiada_wang@mentor.com>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: Stefan Agner <stefan@agner.ch>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Signed-off-by: default avatarTrent Piepho <tpiepho@impinj.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      c842749e
  9. 11 Mar, 2019 1 commit
    • Chris Lesiak's avatar
      spi: Fix zero length xfer bug · 5442dcaa
      Chris Lesiak authored
      This fixes a bug for messages containing both zero length and
      unidirectional xfers.
      
      The function spi_map_msg will allocate dummy tx and/or rx buffers
      for use with unidirectional transfers when the hardware can only do
      a bidirectional transfer.  That dummy buffer will be used in place
      of a NULL buffer even when the xfer length is 0.
      
      Then in the function __spi_map_msg, if he hardware can dma,
      the zero length xfer will have spi_map_buf called on the dummy
      buffer.
      
      Eventually, __sg_alloc_table is called and returns -EINVAL
      because nents == 0.
      
      This fix prevents the error by not using the dummy buffer when
      the xfer length is zero.
      Signed-off-by: default avatarChris Lesiak <chris.lesiak@licor.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      5442dcaa
  10. 04 Mar, 2019 1 commit
  11. 22 Feb, 2019 2 commits
  12. 20 Feb, 2019 2 commits
  13. 19 Feb, 2019 2 commits
  14. 13 Feb, 2019 4 commits
  15. 12 Feb, 2019 3 commits
  16. 08 Feb, 2019 3 commits
  17. 06 Feb, 2019 5 commits