[PATCH v2 0/3] spi: Helper for deriving timeout values

[PATCH v2 0/3] spi: Helper for deriving timeout values

[Miquel Raynal]

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

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(-)

-- 
2.34.1

[PATCH v2 1/3] spi: Create a helper to derive adaptive timeouts

[Miquel Raynal]

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: Mark Brown <broonie@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 include/linux/spi/spi.h | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index fbf8c0d95968..4d6636c50465 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -1186,6 +1186,23 @@ static inline bool spi_is_bpw_supported(struct spi_device *spi, u32 bpw)
 	return false;
 }
 
+/**
+ * spi_controller_xfer_timeout - Compute a suitable timeout value
+ * @ctlr: SPI device
+ * @xfer: Transfer descriptor
+ *
+ * Compute a relevant timeout value for the given transfer. We derive the time
+ * that it would take on a single data line and take twice this amount of time
+ * with a minimum of 500ms to avoid false positives on loaded systems.
+ *
+ * Returns: Transfer timeout value in milliseconds.
+ */
+static inline unsigned int spi_controller_xfer_timeout(struct spi_controller *ctlr,
+						       struct spi_transfer *xfer)
+{
+	return max(xfer->len * 8 * 2 / (xfer->speed_hz / 1000), 500U);
+}
+
 /*---------------------------------------------------------------------------*/
 
 /* SPI transfer replacement methods which make use of spi_res */
-- 
2.34.1

[PATCH v2 2/3] spi: atmel: Prevent false timeouts on long transfers

[Miquel Raynal]

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>
---
 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 c4f22d50dba5..d1743817a5da 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_master *master,
 	struct atmel_spi_device	*asd;
 	int			timeout;
 	int			ret;
-	unsigned long		dma_timeout;
+	unsigned int		dma_timeout;
+	long			ret_timeout;
 
 	as = spi_master_get_devdata(master);
 
@@ -1333,11 +1335,13 @@ static int atmel_spi_one_transfer(struct spi_master *master,
 			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(master, 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

Re: [PATCH v2 2/3] spi: atmel: Prevent false timeouts on long transfers

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Mon, Jun 19, 2023 at 05:53:48PM +0200, Miquel Raynal wrote:
> 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.

This breaks the build:

/build/stage/linux/drivers/spi/spi-atmel.c: In function ‘atmel_spi_one_transfer’
:
/build/stage/linux/drivers/spi/spi-atmel.c:1338:76: error: ‘master’ undeclared (
first use in this function)
 1338 |                 dma_timeout = msecs_to_jiffies(spi_controller_xfer_timeo
ut(master, xfer));
      |                                                                         
   ^~~~~~
/build/stage/linux/drivers/spi/spi-atmel.c:1338:76: note: each undeclared identi
fier is reported only once for each function it appears in

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2 2/3] spi: atmel: Prevent false timeouts on long transfers

[Miquel Raynal]

Hi Mark,

broonie@kernel.org wrote on Wed, 21 Jun 2023 15:59:34 +0100:

> On Mon, Jun 19, 2023 at 05:53:48PM +0200, Miquel Raynal wrote:
> > 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.  
> 
> This breaks the build:
> 
> /build/stage/linux/drivers/spi/spi-atmel.c: In function ‘atmel_spi_one_transfer’
> :
> /build/stage/linux/drivers/spi/spi-atmel.c:1338:76: error: ‘master’ undeclared (
> first use in this function)
>  1338 |                 dma_timeout = msecs_to_jiffies(spi_controller_xfer_timeo
> ut(master, xfer));
>       |                                                                         
>    ^~~~~~
> /build/stage/linux/drivers/spi/spi-atmel.c:1338:76: note: each undeclared identi
> fier is reported only once for each function it appears in

I am testing on a customer board which currently runs on 6.1, I lacked
398b6b310ec8 ("spi: atmel: switch to use modern name"). I'll send an update.

Thanks,
Miquèl

[PATCH v2 3/3] spi: sun6i: Use the new helper to derive the xfer timeout value

[Miquel Raynal]

A helper was recently added to the core to factorize common code between
drivers, like the amount of time a driver should wait for a transfer to
happen.

It is of course possible to use a default value (like eg. 1s) but it is
way stronger to adapt this amount of time to the transfer. Indeed, long
transfers (eg. 4MiB) on a slow single-spi bus might take more than the
usual second of timeout and prevent lengthy transfers.

The core helper was heavily inspired by the logic applied in this
driver, the only difference being the minimum amount of time which was
enlarged from 0.1s to 0.5s.

Use this helper instead of open-coding it.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/spi/spi-sun6i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 23ad052528db..180094dfae19 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -422,7 +422,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
 	reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
 	sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
 
-	tx_time = max(tfr->len * 8 * 2 / (tfr->speed_hz / 1000), 100U);
+	tx_time = spi_controller_xfer_timeout(master, tfr);
 	start = jiffies;
 	timeout = wait_for_completion_timeout(&sspi->done,
 					      msecs_to_jiffies(tx_time));
-- 
2.34.1

Re: [PATCH v2 3/3] spi: sun6i: Use the new helper to derive the xfer timeout value

[Jernej Škrabec]

Dne ponedeljek, 19. junij 2023 ob 17:53:49 CEST je Miquel Raynal napisal(a):
> A helper was recently added to the core to factorize common code between
> drivers, like the amount of time a driver should wait for a transfer to
> happen.
> 
> It is of course possible to use a default value (like eg. 1s) but it is
> way stronger to adapt this amount of time to the transfer. Indeed, long
> transfers (eg. 4MiB) on a slow single-spi bus might take more than the
> usual second of timeout and prevent lengthy transfers.
> 
> The core helper was heavily inspired by the logic applied in this
> driver, the only difference being the minimum amount of time which was
> enlarged from 0.1s to 0.5s.
> 
> Use this helper instead of open-coding it.
> 
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>

Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>

Best regards,
Jernej

> ---
>  drivers/spi/spi-sun6i.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
> index 23ad052528db..180094dfae19 100644
> --- a/drivers/spi/spi-sun6i.c
> +++ b/drivers/spi/spi-sun6i.c
> @@ -422,7 +422,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
>  	reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
>  	sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
>  
> -	tx_time = max(tfr->len * 8 * 2 / (tfr->speed_hz / 1000), 100U);
> +	tx_time = spi_controller_xfer_timeout(master, tfr);
>  	start = jiffies;
>  	timeout = wait_for_completion_timeout(&sspi->done,
>  					      msecs_to_jiffies(tx_time));
> 

Re: [PATCH v2 0/3] spi: Helper for deriving timeout values

[Mark Brown]

On Mon, 19 Jun 2023 17:53:46 +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