1. 18 Mar, 2020 5 commits
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Protect against races on dspi->words_in_flight · 0dedf901
      Vladimir Oltean authored
      dspi->words_in_flight is a variable populated in the *_write functions
      and used in the dspi_fifo_read function. It is also used in
      dspi_fifo_write, immediately after transmission, to update the
      message->actual_length variable used by higher layers such as spi-mem
      for integrity checking.
      
      But it may happen that the IRQ which calls dspi_fifo_read to be
      triggered before the updating of message->actual_length takes place. In
      that case, dspi_fifo_read will decrement dspi->words_in_flight to -1,
      and that will cause an invalid modification of message->actual_length.
      
      For that, we make the simplest fix possible: to not decrement the actual
      shared variable in dspi->words_in_flight from dspi_fifo_read, but
      actually a copy of it which is on stack.
      
      But even if dspi_fifo_read from the next IRQ does not interfere with the
      dspi_fifo_write of the current chunk, the *next* dspi_fifo_write still
      can. So we must assume that everything after the last write to the TX
      FIFO can be preempted by the "TX complete" IRQ, and the dspi_fifo_write
      function must be safe against that. This means refactoring the 2
      flavours of FIFO writes (for EOQ and XSPI) such that the calculation of
      the number of words to be written is common and happens a priori. This
      way, the code for updating the message->actual_length variable works
      with a copy and not with the volatile dspi->words_in_flight.
      
      After some interior debate, the dspi->progress variable used for
      software timestamping was *not* backed up against preemption in a copy
      on stack. Because if preemption does occur between
      spi_take_timestamp_pre and spi_take_timestamp_post, there's really no
      point in trying to save anything. The first-in-time
      spi_take_timestamp_post call with a dspi->progress higher than the
      requested xfer->ptp_sts_word_post will trigger xfer->timestamped = true
      anyway and will close the deal.
      
      To understand the above a bit better, consider a transfer with
      xfer->ptp_sts_word_pre = xfer->ptp_sts_word_post = 3, and
      xfer->bits_per_words = 8 (so byte 3 needs to be timestamped). The DSPI
      controller timestamps in chunks of 4 bytes at a time, and preemption
      occurs in the middle of timestamping the first chunk:
      
        spi_take_timestamp_pre(0)
          .
          . (preemption)
          .
          . spi_take_timestamp_pre(4)
          .
          . spi_take_timestamp_post(7)
          .
        spi_take_timestamp_post(3)
      
      So the reason I'm not bothering to back up dspi->progress for that
      spi_take_timestamp_post(3) is that spi_take_timestamp_post(7) is going
      to (a) be more honest, (b) provide better accuracy and (c) already
      render the spi_take_timestamp_post(3) into a noop by setting
      xfer->timestamped = true anyway.
      
      Fixes: d59c90a2 ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
      Reported-by: default avatarMichael Walle <michael@walle.cc>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Link: https://lore.kernel.org/r/20200318001603.9650-6-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      0dedf901
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Avoid reading more data than written in EOQ mode · c6c1e30a
      Vladimir Oltean authored
      If dspi->words_in_flight is populated with the hardware FIFO size,
      then in dspi_fifo_read it will attempt to read more data at the end of a
      buffer that is not a multiple of 16 bytes in length. It will probably
      time out attempting to do so.
      
      So limit the num_fifo_entries variable to the actual number of FIFO
      entries that is going to be used.
      
      Fixes: d59c90a2 ("spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Link: https://lore.kernel.org/r/20200318001603.9650-5-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c6c1e30a
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Fix bits-per-word acceleration in DMA mode · a957499b
      Vladimir Oltean authored
      In DMA mode, dspi_setup_accel does not get called, which results in the
      dspi->oper_word_size variable (which is used by dspi_dma_xfer) to not be
      initialized properly.
      
      Because oper_word_size is zero, a few calculations end up being
      incorrect, and the DMA transfer eventually times out instead of sending
      anything on the wire.
      
      Set up native transfers (or 8-on-16 acceleration) using dspi_setup_accel
      for DMA mode too.
      
      Also take the opportunity and simplify the DMA buffer handling a little
      bit.
      
      Fixes: 6c1c26ec ("spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Link: https://lore.kernel.org/r/20200318001603.9650-4-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      a957499b
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA · 671ffde1
      Vladimir Oltean authored
      In XSPI mode, the 32-bit PUSHR register can be written to separately:
      the higher 16 bits are for commands and the lower 16 bits are for data.
      
      This has nicely been hacked around, by defining a second regmap with a
      width of 16 bits, and effectively splitting a 32-bit register into 2
      16-bit ones, from the perspective of this regmap_pushr.
      
      The problem is the assumption about the controller's endianness. If the
      controller is little endian (such as anything post-LS1046A), then the
      first 2 bytes, in the order imposed by memory layout, will actually hold
      the TXDATA, and the last 2 bytes will hold the CMD.
      
      So take the controller's endianness into account when performing split
      writes to PUSHR. The obvious and simple solution would have been to call
      regmap_get_val_endian(), but that is an internal regmap function and we
      don't want to change regmap just for this. Therefore, we just re-read
      the "big-endian" device tree property.
      
      Fixes: 58ba07ec ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      671ffde1
    • Vladimir Oltean's avatar
      spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR · 4fcc7c22
      Vladimir Oltean authored
      The SPI_MCR_PCSIS macro assumes that the controller has a number of chip
      select signals equal to 6. That is not always the case, but actually is
      described through the driver-specific "spi-num-chipselects" device tree
      binding. LS1028A for example only has 4 chip selects.
      
      Don't write to the upper bits of the PCSIS field, which are reserved in
      the reference manual.
      
      Fixes: 349ad66c ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarMichael Walle <michael@walle.cc>
      Link: https://lore.kernel.org/r/20200318001603.9650-2-olteanv@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      4fcc7c22
  2. 17 Mar, 2020 1 commit
  3. 13 Mar, 2020 2 commits
  4. 12 Mar, 2020 12 commits
  5. 11 Mar, 2020 6 commits
  6. 10 Mar, 2020 7 commits
  7. 06 Mar, 2020 1 commit
  8. 05 Mar, 2020 6 commits
    • Mark Brown's avatar
      Merge series "TCFQ to XSPI migration for NXP DSPI driver" from Vladimir Oltean <olteanv@gmail.com> · 4a8ee2ab
      Mark Brown authored
      Vladimir Oltean <vladimir.oltean@nxp.com>:
      
      From: Vladimir Oltean <vladimir.oltean@nxp.com>
      
      This series aims to remove the most inefficient transfer method from the
      NXP DSPI driver.
      
      TCFQ (Transfer Complete Flag) mode works by transferring one word,
      waiting for its TX confirmation interrupt (or polling on the equivalent
      status bit), sending the next word, etc, until the buffer is complete.
      
      The issue with this mode is that it's fundamentally incompatible with
      any sort of batching such as writing to a FIFO. But actually, due to
      previous patchset ("Compatible string consolidation for NXP DSPI driver"):
      
      https://patchwork.kernel.org/cover/11414593/
      
      all existing users of TCFQ mode today already support a more advanced
      feature set, in the form of XSPI (extended SPI). XSPI brings 2 extra
      features:
      
      - Word sizes up to 32 bits. This is sub-utilized today, and acceleration
        of smaller-than-32 bpw values is provided.
      - "Command cycling", basically the ability to write multiple words in a
        row and receiving an interrupt only after the completion of the last
        one. This is what enables us to make use of the full FIFO depth of
        this controller.
      
      Series was tested on the NXP LS1021A-TSN and LS1043A-RDB boards, both
      functionally as well as from a performance standpoint.
      
      The command used to benchmark the increased throughput was:
      
      spidev_test --device /dev/spidev1.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000
      
      where spidev1.0 is a dummy spidev node, using a chip select that no
      peripheral responds to.
      
      On LS1021A, which has a 4-entry-deep FIFO and a less powerful CPU, the
      performance increase brought by this patchset is from 2700 kbps to 5800
      kbps.
      
      On LS1043A, which has a 16-entry-deep FIFO and a more powerful CPU, the
      performance increases from 4100 kbps to 13700 kbps.
      
      On average, SPI software timestamping is not adversely affected by the
      extra batching, due to the extra patches.
      
      There is one extra patch which clarifies why the TCFQ users were not
      converted to the "other" mode in this driver that makes use of the FIFO,
      which would be EOQ mode.
      
      My request to the many people on CC (known users and/or contributors) is
      to give this series a test to ensure there are no regressions, and for
      the Coldfire maintainers to clarify whether the EOQ limitation is
      acceptable for them in the long run.
      
      Vladimir Oltean (12):
        spi: spi-fsl-dspi: Simplify bytes_per_word gymnastics
        spi: spi-fsl-dspi: Remove unused chip->void_write_data
        spi: spi-fsl-dspi: Don't mask off undefined bits
        spi: spi-fsl-dspi: Add comments around dspi_pop_tx and dspi_push_rx
          functions
        spi: spi-fsl-dspi: Rename fifo_{read,write} and {tx,cmd}_fifo_write
        spi: spi-fsl-dspi: Implement .max_message_size method for EOQ mode
        spi: Do spi_take_timestamp_pre for as many times as necessary
        spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode
        spi: spi-fsl-dspi: Accelerate transfers using larger word size if
          possible
        spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt
          count
        spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI mode
        spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_write
      
       drivers/spi/spi-fsl-dspi.c | 421 ++++++++++++++++++++++++-------------
       drivers/spi/spi.c          |  19 +-
       include/linux/spi/spi.h    |   3 +-
       3 files changed, 288 insertions(+), 155 deletions(-)
      
      --
      2.17.1
      4a8ee2ab
    • Johan Jonker's avatar
      dt-bindings: spi: spi-rockchip: add description for rk3328 · 6ac12131
      Johan Jonker authored
      The description below is already in use for rk3328.dtsi,
      but was somehow never added to a document, so add
      "rockchip,rk3328-spi", "rockchip,rk3066-spi"
      for spi nodes on a rk3328 platform to spi-rockchip.yaml.
      Signed-off-by: default avatarJohan Jonker <jbx6244@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20200304184203.9548-3-jbx6244@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      6ac12131
    • Johan Jonker's avatar
      dt-bindings: spi: spi-rockchip: add description for rk3308 · db7dd939
      Johan Jonker authored
      The description below is already in use for rk3308.dtsi,
      but was somehow never added to a document, so add
      "rockchip,rk3308-spi", "rockchip,rk3066-spi"
      for spi nodes on a rk3308 platform to spi-rockchip.yaml.
      Signed-off-by: default avatarJohan Jonker <jbx6244@gmail.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20200304184203.9548-2-jbx6244@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      db7dd939
    • Johan Jonker's avatar
      dt-bindings: spi: convert rockchip spi bindings to yaml · 5de04175
      Johan Jonker authored
      Current dts files with 'spi' nodes are manually verified.
      In order to automate this process spi-rockchip.txt
      has to be converted to yaml. In the new setup
      spi-rockchip.yaml will inherit properties from
      spi-controller.yaml.
      
      Add document to MAINTAINERS.
      
      Also rk3188.dtsi, rk3288.dtsi, rk3368.dtsi and rk3399.dtsi
      use an extra fallback string, so change this in the documentation.
      
      Changed:
      "rockchip,rk3188-spi", "rockchip,rk3066-spi"
      "rockchip,rk3288-spi", "rockchip,rk3066-spi"
      "rockchip,rk3368-spi", "rockchip,rk3066-spi"
      "rockchip,rk3399-spi", "rockchip,rk3066-spi"
      Signed-off-by: default avatarJohan Jonker <jbx6244@gmail.com>
      Link: https://lore.kernel.org/r/20200304184203.9548-1-jbx6244@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      5de04175
    • Sascha Hauer's avatar
      spi: spi-fsl-dspi: Make bus-num property optional · 29d2daf2
      Sascha Hauer authored
      The SPI bus number is completely optional to Linux, so make the
      corresponding device tree property optional as well.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Link: https://lore.kernel.org/r/20200305115546.31814-1-s.hauer@pengutronix.deSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      29d2daf2
    • Adam Ford's avatar
      spi: spi-nxp-fspi: Add support for imx8mm, imx8qxp · c7a1a20e
      Adam Ford authored
      Add support for nxp,imx8qxp-fspi and nxp,imx8mm-fspi do the bindings
      document.
      Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
      
      Link: https://lore.kernel.org/r/20200126140913.2139260-4-aford173@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c7a1a20e