1. 19 9月, 2017 1 次提交
    • J
      spi: imx: Add support for SPI Slave mode · 71abd290
      jiada wang 提交于
      Previously i.MX SPI controller only works in Master mode.
      This patch adds support to i.MX51, i.MX53 and i.MX6 ECSPI
      controller to work also in Slave mode.
      
      Currently SPI Slave mode support patch has the following limitations:
      1. The stale data in RXFIFO will be dropped when the Slave does any new
         transfer.
      2. One transfer can be finished only after all transfer->len data been
         transferred to master device
      3. Slave device only accepts transfer->len data. Any data longer than this
         from master device will be dropped. Any data shorter than this from
         master will cause SPI to stuck due to mentioned HW limitation 2.
      4. Only PIO transfer is supported in Slave mode.
      5. Dynamic burst size adjust isn't supported in Slave mode.
      
      Following HW limitation applies:
      1.  ECSPI has a HW issue when works in Slave mode, after 64
          words written to TXFIFO, even TXFIFO becomes empty,
          ECSPI_TXDATA keeps shift out the last word data,
          so we have to disable ECSPI when in slave mode after the
          transfer completes
      2.  Due to Freescale errata ERR003775 "eCSPI: Burst completion by Chip
          Select (SS) signal in Slave mode is not functional" burst size must
          be set exactly to the size of the transfer. This limit SPI transaction
          with maximum 2^12 bits. This errata affects i.MX53 and i.MX6 ECSPI
          controllers.
      Signed-off-by: NJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      71abd290
  2. 30 8月, 2017 1 次提交
    • G
      spi: imx: fix use of native chip-selects with devicetree · 602c8f44
      Greg Ungerer 提交于
      The commonly used mechanism of specifying the hardware or native
      chip-select on an SPI device in devicetree (that is "cs-gpios = <0>")
      does not result in the native chip-select being configured for use.
      So external SPI devices that require use of the native chip-select
      will not work.
      
      You can successfully specify native chip-selects if using a platform
      setup by specifying the cs-gpio as negative offset by 32. And that
      works correctly. You cannot use the same method in devicetree.
      
      The logic in the spi-imx.c driver during probe uses core spi function
      of_spi_register_master() in spi.c to parse the "cs-gpios" devicetree tag.
      For valid GPIO values that will be recorded for use, all other entries in
      the cs_gpios list will be set to -ENOENT. So entries like "<0>" will be
      set to -ENOENT in the cs_gpios list.
      
      When the SPI device registers are setup the code will use the GPIO
      listed in the cs_gpios list for the desired chip-select. If the cs_gpio
      is less then 0 then it is intended to be for a native chip-select, and
      its cs_gpio value is added to 32 to get the chipselect number to use.
      Problem is that with devicetree this can only ever be -ENOENT (which
      is -2), and that alone results in an invalid chip-select number. But also
      doesn't allow selection of the native chip-select at all.
      
      To fix, if the cs_gpio specified for this spi device is not a
      valid GPIO then use the "chip_select" (that is the native chip-select
      number) for hardware setup.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      Reviewed-by: NVladimir Zapolskiy <vz@mleia.com>
      Tested-by: NVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      602c8f44
  3. 23 8月, 2017 1 次提交
    • A
      spi: imx: fix little-endian build · 5904c9d3
      Arnd Bergmann 提交于
      The newly added dynamic burst code produces a harmless warning
      on big-endian configurations:
      
      drivers/spi/spi-imx.c: In function 'spi_imx_buf_rx_swap_u32':
      drivers/spi/spi-imx.c:284:15: error: unused variable 'bytes_per_word' [-Werror=unused-variable]
        unsigned int bytes_per_word;
                     ^~~~~~~~~~~~~~
      drivers/spi/spi-imx.c: In function 'spi_imx_buf_tx_swap_u32':
      drivers/spi/spi-imx.c:319:15: error: unused variable 'bytes_per_word' [-Werror=unused-variable]
        unsigned int bytes_per_word;
      
      This adds another #ifdef around the variable declaration matching
      the one on the use.
      
      Fixes: 1673c81d ("spi: imx: dynamic burst length adjust for PIO mode")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      5904c9d3
  4. 17 8月, 2017 1 次提交
  5. 26 7月, 2017 1 次提交
  6. 17 7月, 2017 2 次提交
  7. 21 6月, 2017 1 次提交
  8. 07 6月, 2017 6 次提交
  9. 24 5月, 2017 1 次提交
  10. 20 5月, 2017 1 次提交
  11. 14 5月, 2017 1 次提交
  12. 25 4月, 2017 1 次提交
  13. 07 1月, 2017 1 次提交
  14. 02 11月, 2016 1 次提交
  15. 25 10月, 2016 1 次提交
  16. 29 9月, 2016 1 次提交
  17. 27 9月, 2016 1 次提交
  18. 15 9月, 2016 2 次提交
  19. 22 6月, 2016 1 次提交
    • C
      spi: imx: wait_for_completion_timeout(..) for PIO transfers · ff1ba3da
      Christian Gmeiner 提交于
      In some rare cases I see the following 'task blocked' information. It
      looks like the PIO transfer has some problems and never succeeds. Make
      use of wait_for_completion_timeout(..) to detect this case and
      return -ETIMEDOUT.
      
      [ 240.246067] INFO: task hexdump:1660 blocked for more than 120 seconds.
      [ 240.246089] Not tainted 4.1.17 0000001
      [ 240.246099] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [ 240.246109] hexdump D c0575548 0 1660 1 0x00000000
      [ 240.246132] Backtrace:
      [ 240.246166] [<c057524c>] (__schedule) from [<c0575a84>] (schedule+0x40/0xa4)
      [ 240.246176] r10:00000000 r9:c07f1300 r8:c07b8408 r7:c0576518 r6:7fffffff r5:7fffffff
      [ 240.246210] r4:ee972e7c
      [ 240.246233] [<c0575a44>] (schedule) from [<c0578544>] (schedule_timeout+0x174/0x274)
      [ 240.246254] [<c05783d0>] (schedule_timeout) from [<c0576518>] (wait_for_common+0xc0/0x164)
      [ 240.246263] r10:00000000 r9:c07f1300 r8:00000002 r7:00000000 r6:7fffffff r5:ee972e78
      [ 240.246294] r4:ee972e7c
      [ 240.246314] [<c0576458>] (wait_for_common) from [<c05765dc>] (wait_for_completion+0x20/0x24)
      [ 240.246324] r10:ee972e50 r8:00000001 r7:c3976200 r6:ee972c00 r5:ee972e50 r4:c2c87d28
      [ 240.246367] [<c05765bc>] (wait_for_completion) from [<c03f6b04>] (spi_imx_transfer+0xe8/0x3cc)
      [ 240.246393] [<c03f6a1c>] (spi_imx_transfer) from [<c03f50e4>] (spi_bitbang_transfer_one+0xb4/0x250)
      [ 240.246403] r10:ee972e50 r8:00000001 r7:00000000 r6:c2c87da0 r5:00000000 r4:c2c87d28
      [ 240.246443] [<c03f5030>] (spi_bitbang_transfer_one) from [<c03f36e8>] (__spi_pump_messages+0x36c/0x6b4)
      [ 240.246452] r10:ee9e5010 r9:00000001 r8:ee9e5010 r7:00000000 r6:c2c87da0 r5:c2c87d6c
      [ 240.246483] r4:ee972c00
      [ 240.246503] [<c03f337c>] (__spi_pump_messages) from [<c03f3b68>] (__spi_sync+0x138/0x1e4)
      [ 240.246512] r10:00000000 r9:00000000 r8:c03f25a8 r7:00000000 r6:ee972c00 r5:c3976200
      [ 240.246542] r4:c2c87da0
      [ 240.246562] [<c03f3a30>] (__spi_sync) from [<c03f3c50>] (spi_sync+0x1c/0x20)
      [ 240.246571] r10:00040000 r9:00000000 r8:c3976200 r7:00000000 r6:ee973300 r5:c2c87da0
      [ 240.246602] r4:ee973014
      [ 240.246623] [<c03f3c34>] (spi_sync) from [<c03f0210>] (m25p80_read+0xf8/0x124)
      [ 240.246641] [<c03f0118>] (m25p80_read) from [<c03f1528>] (spi_nor_read+0x64/0x80)
      [ 240.246651] r10:00004000 r8:00004000 r7:00000000 r6:00040000 r5:00000000 r4:ee973014
      [ 240.246698] [<c03f14c4>] (spi_nor_read) from [<c03cdcb4>] (mtd_read+0x98/0xcc)
      [ 240.246708] r7:c2c87ea0 r6:ee973098 r5:00000000 r4:001c0000
      [ 240.246740] [<c03cdc1c>] (mtd_read) from [<c03d300c>] (mtdchar_read+0xcc/0x204)
      [ 240.246750] r9:ed424000 r8:00000000 r7:b495d018 r6:c2c87f78 r5:00000000 r4:00040000
      [ 240.246793] [<c03d2f40>] (mtdchar_read) from [<c013b1c4>] (__vfs_read+0x3c/0xe0)
      [ 240.246803] r10:00004000 r9:00000000 r8:c2c87f78 r7:b495d018 r6:c2c87f78 r5:c05c8104
      [ 240.246833] r4:c32fe600
      [ 240.246852] [<c013b188>] (__vfs_read) from [<c013befc>] (vfs_read+0x98/0x154)
      [ 240.246861] r10:00000000 r8:00040000 r7:00004000 r6:c2c87f78 r5:b495d018 r4:c32fe600
      [ 240.246899] [<c013be64>] (vfs_read) from [<c013c008>] (SyS_read+0x50/0x90)
      [ 240.246908] r10:00000000 r8:00040000 r7:b495d018 r6:00004000 r5:c32fe601 r4:c32fe600
      [ 240.246953] [<c013bfb8>] (SyS_read) from [<c000fa60>] (ret_fast_syscall+0x0/0x3c)
      [ 240.246962] r9:c2c86000 r8:c000fc04 r7:00000003 r6:00004000 r5:00000000 r4:b495d018
      Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      ff1ba3da
  20. 14 6月, 2016 3 次提交
  21. 17 3月, 2016 2 次提交
  22. 26 2月, 2016 8 次提交
  23. 24 2月, 2016 1 次提交
    • S
      spi: imx: drop fallback to PIO · 99f1cf1c
      Sascha Hauer 提交于
      At the moment the driver decides to fallback to PIO mode the buffers
      are already mapped for DMA. It's a bug to access them with the CPU
      afterwards, so we cannot just fallback to PIO mode.
      It should not be necessary anyway, since we only use DMA when we
      verified that it's possible in the fist place, so when prep_slave_sg
      fails it's a bug, either in the SDMA driver or in the can_dma
      implementation.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      99f1cf1c