1. 22 Jun, 2023 2 commits
    • Miquel Raynal's avatar
      spi: atmel: Prevent false timeouts on long transfers · e0205d62
      Miquel Raynal authored
      A slow SPI bus clocks at ~20MHz, which means it would transfer about
      2500 bytes per second with a single data line. Big transfers, like when
      dealing with flashes can easily reach a few MiB. The current DMA timeout
      is set to 1 second, which means any working transfer of about 4MiB will
      always be cancelled.
      
      With the above derivations, on a slow bus, we can assume every byte will
      take at most 0.4ms. Said otherwise, we could add 4ms to the 1-second
      timeout delay every 10kiB. On a 4MiB transfer, it would bring the
      timeout delay up to 2.6s which still seems rather acceptable for a
      timeout.
      
      The consequence of this is that long transfers might be allowed, which
      hence requires the need to interrupt the transfer if wanted by the
      user. We can hence switch to the _interruptible variant of
      wait_for_completion. This leads to a little bit more handling to also
      handle the interrupted case but looks really acceptable overall.
      
      While at it, we drop the useless, noisy and redundant WARN_ON() call.
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Acked-by: default avatarRyan Wanner <ryan.wanner@microchip.com>
      Link: https://lore.kernel.org/r/Message-Id: <20230622090634.3411468-3-miquel.raynal@bootlin.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      e0205d62
    • Miquel Raynal's avatar
      spi: Create a helper to derive adaptive timeouts · d8e4ebf8
      Miquel Raynal authored
      Big transfers might take a bit of time, too constraining timeouts might
      lead to false positives. In order to simplify the drivers work and with
      the goal of factorizing code in mind, let's add a helper that can be
      used by any spi controller driver to derive a relevant per-transfer
      timeout value.
      
      The logic is simple: we know how much time it would take to transfer a
      byte, we can easily derive the total theoretical amount of time involved
      for each transfer. We multiply it by two to have a bit of margin and
      enforce a minimum of 500ms.
      Suggested-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Link: https://lore.kernel.org/r/Message-Id: <20230622090634.3411468-2-miquel.raynal@bootlin.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      d8e4ebf8
  2. 15 Jun, 2023 4 commits
  3. 07 Jun, 2023 2 commits
  4. 06 Jun, 2023 4 commits
  5. 02 Jun, 2023 2 commits
  6. 01 Jun, 2023 4 commits
  7. 31 May, 2023 2 commits
  8. 30 May, 2023 18 commits
  9. 26 May, 2023 1 commit
  10. 25 May, 2023 1 commit