| Message ID | 20230622090634.3411468-1-miquel.raynal@bootlin.com |
|---|---|
| Headers | show |
| Series | spi: Helper for deriving timeout values | expand |
On 6/22/23 02:06, Miquel Raynal wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > 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: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Ryan Wanner <ryan.wanner@microchip.com> > --- > drivers/spi/spi-atmel.c | 18 +++++++++++------- > 1 file changed, 11 insertions(+), 7 deletions(-) > > diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c > index 943548aab8af..d87be2890597 100644 > --- a/drivers/spi/spi-atmel.c > +++ b/drivers/spi/spi-atmel.c > @@ -233,7 +233,8 @@ > */ > #define DMA_MIN_BYTES 16 > > -#define SPI_DMA_TIMEOUT (msecs_to_jiffies(1000)) > +#define SPI_DMA_MIN_TIMEOUT (msecs_to_jiffies(1000)) > +#define SPI_DMA_TIMEOUT_PER_10K (msecs_to_jiffies(4)) > > #define AUTOSUSPEND_TIMEOUT 2000 > > @@ -1279,7 +1280,8 @@ static int atmel_spi_one_transfer(struct spi_controller *host, > struct atmel_spi_device *asd; > int timeout; > int ret; > - unsigned long dma_timeout; > + unsigned int dma_timeout; > + long ret_timeout; > > as = spi_controller_get_devdata(host); > > @@ -1333,11 +1335,13 @@ static int atmel_spi_one_transfer(struct spi_controller *host, > atmel_spi_unlock(as); > } > > - dma_timeout = wait_for_completion_timeout(&as->xfer_completion, > - SPI_DMA_TIMEOUT); > - if (WARN_ON(dma_timeout == 0)) { > - dev_err(&spi->dev, "spi transfer timeout\n"); > - as->done_status = -EIO; > + dma_timeout = msecs_to_jiffies(spi_controller_xfer_timeout(host, xfer)); > + ret_timeout = wait_for_completion_interruptible_timeout(&as->xfer_completion, > + dma_timeout); > + if (ret_timeout <= 0) { > + dev_err(&spi->dev, "spi transfer %s\n", > + !ret_timeout ? "timeout" : "canceled"); > + as->done_status = ret_timeout < 0 ? ret_timeout : -EIO; > } > > if (as->done_status) > -- > 2.34.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Jernej, jernej.skrabec@gmail.com wrote on Thu, 22 Jun 2023 18:46:27 +0200: > Dne četrtek, 22. junij 2023 ob 11:06:31 CEST je Miquel Raynal napisal(a): > > Hello, > > > > I recently came across an issue with the Atmel spi controller driver > > which would stop my transfers after a too small timeout when performing > > big transfers (reading a 4MiB flash in one transfer). My initial idea > > was to derive a the maximum amount of time a transfer would take > > depending on its size and use that as value to avoid erroring-out when > > not relevant. Mark wanted to go further by creating a core helper doing > > that, based on the heuristics from the sun6i driver. > > > > Here is a small series of 3 patches doing exactly that. > > > > Cheers, > > Miquèl > > > > Changes in v3: > > * Collected a tag. > > Did you? I don't see my a-b at patch 3. I thought I did, sorry if I missed it. Do you mind re-sending it? > > Best regards, > Jernej > > > * As my platform runs on 6.1 currently, I cherry-picked a mainline patch > > changing s/master/host/ in the atmel controller driver and modified the > > series to fit the new naming. I then cherry-picked my three patches and > > verified it compiled correctly against a v6.4-rc1. > > > > Miquel Raynal (3): > > spi: Create a helper to derive adaptive timeouts > > spi: atmel: Prevent false timeouts on long transfers > > spi: sun6i: Use the new helper to derive the xfer timeout value > > > > drivers/spi/spi-atmel.c | 18 +++++++++++------- > > drivers/spi/spi-sun6i.c | 2 +- > > include/linux/spi/spi.h | 17 +++++++++++++++++ > > 3 files changed, 29 insertions(+), 8 deletions(-) > > > > > > > > Thanks, Miquèl
On Thu, 22 Jun 2023 11:06:31 +0200, Miquel Raynal wrote: > I recently came across an issue with the Atmel spi controller driver > which would stop my transfers after a too small timeout when performing > big transfers (reading a 4MiB flash in one transfer). My initial idea > was to derive a the maximum amount of time a transfer would take > depending on its size and use that as value to avoid erroring-out when > not relevant. Mark wanted to go further by creating a core helper doing > that, based on the heuristics from the sun6i driver. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/3] spi: Create a helper to derive adaptive timeouts commit: d8e4ebf87018736c0c29e2eb4afe3915156483cd [2/3] spi: atmel: Prevent false timeouts on long transfers commit: e0205d6203c2ce598ae26d4b2707ca4224a9c90b [3/3] spi: sun6i: Use the new helper to derive the xfer timeout value commit: 6eef895581c9b5fcd002ff77837e0c3a4b1eecf6 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark