1. 18 Jul, 2022 3 commits
  2. 14 Jul, 2022 1 commit
  3. 13 Jul, 2022 11 commits
  4. 11 Jul, 2022 3 commits
  5. 06 Jul, 2022 6 commits
  6. 04 Jul, 2022 2 commits
  7. 01 Jul, 2022 1 commit
  8. 30 Jun, 2022 5 commits
  9. 29 Jun, 2022 6 commits
  10. 28 Jun, 2022 1 commit
    • Mark Brown's avatar
      Optimize spi_sync path · 152f2494
      Mark Brown authored
      Merge series from David Jander <david@protonic.nl>:
      
      These patches optimize the spi_sync call for the common case that the
      worker thread is idle and the queue is empty. It also opens the
      possibility to potentially further optimize the async path also, since
      it doesn't need to take into account the direct sync path anymore.
      
      As an example for the performance gain, on an i.MX8MM SoC with a SPI CAN
      controller attached (MCP2518FD), the time the interrupt line stays
      active (which corresponds roughly with the time it takes to send 3
      relatively short consecutive spi_sync messages) is reduced from 98us to
      only 72us by this patch.
      
      A note about message ordering:
      
      This patch series should not change the behavior of message ordering when
      coming from the same context. This means that if a client driver issues
      one or more spi_async() messages immediately followed by a spi_sync()
      message in the same context, it can still rely on these messages being
      sent out in the order they were fired.
      152f2494
  11. 27 Jun, 2022 1 commit
    • Chanho Park's avatar
      spi: s3c64xx: move dma_release_channel to unprepare · 82295bc0
      Chanho Park authored
      This fixes the sequence of dma_release_channel.
      Since commit f52b03c7 ("spi: s3c64xx: requests spi-dma channel only
      during data transfer"),
      dma_release_channel has been located in the s3c64xx_spi_transfer_one
      but this makes invalid return of can_dma callback.
      __spi_unmap_msg will check whether the request is requested by dma or
      not via can_dma callback. When it is calling to check it, the channels
      will be already released at the end of s3c64xx_spi_transfer_one so the
      callback function will return always "false". So, they can't be unmapped
      from __spi_unmap_msg call. To fix this, we need to add
      unprepare_transfer_hardware callback and move the dma_release_channel
      from s3c64xx_spi_transfer_one to there.
      
      Fixes: f52b03c7 ("spi: s3c64xx: requests spi-dma channel only during data transfer")
      Signed-off-by: default avatarChanho Park <chanho61.park@samsung.com>
      Link: https://lore.kernel.org/r/20220627013845.138350-1-chanho61.park@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      82295bc0