1. 02 Aug, 2019 1 commit
  2. 19 Jun, 2019 1 commit
  3. 30 Jan, 2019 1 commit
  4. 09 Jan, 2019 1 commit
    • Linus Walleij's avatar
      spi: atmel: Convert to use CS GPIO descriptors · efc92fbb
      Linus Walleij authored and Mark Brown's avatar Mark Brown committed
      
      
      This converts the Atmel SPI master driver to use GPIO descriptors
      for chip select handling.
      
      The Atmel driver has duplicate code to look up and initialize CS
      GPIOs from the device tree, so this is removed. It further has code
      to retrieve a CS GPIO from .controller_data but this seems to be
      completely unused in the kernel (legacy codepath?) so I deleted
      this support. It keeps track of polarity when switching the CS, but
      this is not needed anymore since we moved this over to the gpiolib.
      
      The local handling of the "npcs_pin" (I guess this might mean
      "negative polarity chip select pin") is preserved, but I strongly
      suspect this can be switched over to handling by the core and
      using the SPI_MASTER_GPIO_SS flag on the master to assure that
      the additional CS handling in the driver is also done.
      
      Cc: Eugen Hristev <eugen.hristev@microchip.com>
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Radu Pirea <radu.pirea@microchip.com>
      Cc: Linuxarm <linuxarm@huawei.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
      efc92fbb
  5. 05 Sep, 2018 1 commit
  6. 28 Mar, 2018 1 commit
  7. 27 Feb, 2018 1 commit
  8. 05 Jan, 2018 1 commit
  9. 19 Dec, 2017 1 commit
  10. 23 Jun, 2017 1 commit
    • Cyrille Pitchen's avatar
      spi: atmel: fix corrupted data issue on SAM9 family SoCs · 7094576c
      Cyrille Pitchen authored and Mark Brown's avatar Mark Brown committed
      
      
      This patch disables the use of the DMA for data transfer and forces the
      use of PIO transfers instead as a quick fixup to solve the cache aliasing
      issue on ARM9 based cores, which embeds a VIVT data cache.
      
      Indeed in the case of VIVT data caches, it is not safe to call dma_map_*()
      functions to map buffers for DMA transfers when those buffers have been
      allocated by vmalloc() or from any DMA-unsafe area.
      
      Further patches may propose a better solution based on the use of a bounce
      buffer at the SPI sub-system level but such solution needs more time to be
      discussed. Then the use of DMA transfers could be enabled again to improve
      the performances but before that, this patch already solves the issue.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@microchip.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      7094576c
  11. 06 Jun, 2017 1 commit
  12. 18 Apr, 2017 1 commit
  13. 12 Apr, 2017 1 commit
  14. 25 Nov, 2016 5 commits
  15. 15 Nov, 2016 1 commit
  16. 14 Nov, 2016 1 commit
  17. 09 Nov, 2016 1 commit
  18. 28 Jan, 2016 1 commit
  19. 22 Oct, 2015 1 commit
  20. 25 Sep, 2015 1 commit
  21. 17 Sep, 2015 1 commit
  22. 10 Sep, 2015 1 commit
  23. 10 Aug, 2015 1 commit
  24. 16 Jun, 2015 1 commit
    • Cyrille Pitchen's avatar
      spi: atmel: add support to FIFOs · 11f2764f
      Cyrille Pitchen authored and Mark Brown's avatar Mark Brown committed
      
      
      The latest SPI controllers embedded inside sama5d2x SoCs come with FIFOs.
      When FIFOs are enabled, they can either work in SINGLE data mode or
      MULTIPLE data mode. The selected mode depends on the configuration of the
      SPI controller (see below).
      
      In SINGLE data mode (or legacy mode), for a single I/O access, only one
      data can be read from the Receive Data Register (RDR) or written into the
      Transmit Data Register (TDR). On the other hand, in MULTIPLE data mode, up
      to 4 data can be read from the RDR or up 2 data can be written into the
      TDR in a single 32bit I/O access. So programmers should take good care of
      the width of the I/O access to read/write the right number of data. The
      exact number of read/written data depends on both the I/O access width and
      the data width (from 8 up to 16 bits).
      
      To enable the FIFO feature a "atmel,fifo-size" property must be set to
      provide the maximum number of data (not bytes) the RX and TX FIFOs can
      store. Hence a 32 data FIFO can always store up to 32 data unrelated with
      the actual data width.
      
      When FIFOs are enabled, the RX one is forced to operate in SINGLE data
      mode because this driver configures the spi controller as a master. In
      master mode only, the Received Data Register has an additionnal Peripheral
      Chip Select field, which prevents us from reading more than a single data
      at each register access.
      
      Besides, the TX FIFO operates in MULTIPLE data mode. However, even when a
      8bit data size is used, only two data by access could be written into the
      Transmit Data Register. Indeed the first data has to be written into the
      lowest 16 bits whereas the second data has to be written into the highest
      16 bits of the TDR. When DMA transfers are used to send data, we don't
      rework the transmit buffer to cope with this hardware limitation: the
      additional copies required to prepare a new input buffer suited to both
      the DMA controller and the spi controller would waste all the benefit of
      the DMA transfer. Instead, the DMA controller is configured to write only
      one data at time into the TDR.
      
      In pio mode, two data are written in the TDR in a single access.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
      11f2764f
  25. 09 Jun, 2015 1 commit
    • Cyrille Pitchen's avatar
      spi: atmel: add support for the internal chip-select of the spi controller · 48203034
      Cyrille Pitchen authored and Mark Brown's avatar Mark Brown committed
      
      
      This patch relies on the CSAAT (Chip Select Active After Transfer) feature
      introduced by the version 2 of the spi controller. This new mode allows to
      use properly the internal chip-select output pin of the spi controller
      instead of using external gpios. Consequently, the "cs-gpios" device-tree
      property becomes optional.
      
      When the new CSAAT bit is set into the Chip Select Register, the internal
      chip-select output pin remains asserted till both the following conditions
      become true:
      - the LASTXFER bit is set into the Control Register (or the Transmit Data
        Register)
      - the Transmit Data Register and its shift register are empty.
      
      WARNING: if the LASTXFER bit is set into the Control Register then new
      data are written into the Transmit Data Register fast enough to keep its
      shifter not empty, the chip-select output pin remains asserted. Only when
      the shifter becomes empty, the chip-select output pin is unasserted.
      
      When the CSAAT bit is clear in the Chip Select Register, the LASTXFER bit
      is ignored in both the Control Register and the Transmit Data Register.
      The internal chip-select output pin remains active as long as the Transmit
      Data Register or its shift register are not empty.
      Signed-off-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
      48203034
  26. 22 Mar, 2015 1 commit
  27. 26 Feb, 2015 1 commit
    • Torsten Fleischer's avatar
      spi: atmel: Fix interrupt setup for PDC transfers · 76e1d14b
      Torsten Fleischer authored and Mark Brown's avatar Mark Brown committed
      
      
      Additionally to the current DMA transfer the PDC allows to set up a next DMA
      transfer. This is useful for larger SPI transfers.
      
      The driver currently waits for ENDRX as end of the transfer. But ENDRX is set
      when the current DMA transfer is done (RCR = 0), i.e. it doesn't include the
      next DMA transfer.
      Thus a subsequent SPI transfer could be started although there is currently a
      transfer in progress. This can cause invalid accesses to the SPI slave devices
      and to SPI transfer errors.
      
      This issue has been observed on a hardware with a M25P128 SPI NOR flash.
      
      So instead of ENDRX we should wait for RXBUFF. This flag is set if there is
      no more DMA transfer in progress (RCR = RNCR = 0).
      Signed-off-by: default avatarTorsten Fleischer <torfl6749@gmail.com>
      Signed-off-by: Mark Brown's avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      76e1d14b
  28. 04 Feb, 2015 1 commit
  29. 24 Nov, 2014 2 commits
  30. 21 Oct, 2014 1 commit
  31. 20 Oct, 2014 4 commits
  32. 01 Aug, 2014 1 commit