aboutsummaryrefslogtreecommitdiffstats
path: root/target/linux/lantiq
diff options
context:
space:
mode:
Diffstat (limited to 'target/linux/lantiq')
-rw-r--r--target/linux/lantiq/patches-4.9/0093-spi-double-time-out-tolerance.patch37
1 files changed, 37 insertions, 0 deletions
diff --git a/target/linux/lantiq/patches-4.9/0093-spi-double-time-out-tolerance.patch b/target/linux/lantiq/patches-4.9/0093-spi-double-time-out-tolerance.patch
new file mode 100644
index 0000000000..68b0ffe570
--- /dev/null
+++ b/target/linux/lantiq/patches-4.9/0093-spi-double-time-out-tolerance.patch
@@ -0,0 +1,37 @@
+From 833bfade96561216aa2129516a5926a0326860a2 Mon Sep 17 00:00:00 2001
+From: Hauke Mehrtens <hauke@hauke-m.de>
+Date: Mon, 17 Apr 2017 01:38:05 +0200
+Subject: spi: double time out tolerance
+
+The generic SPI code calculates how long the issued transfer would take
+and adds 100ms in addition to the timeout as tolerance. On my 500 MHz
+Lantiq Mips SoC I am getting timeouts from the SPI like this when the
+system boots up:
+
+m25p80 spi32766.4: SPI transfer timed out
+blk_update_request: I/O error, dev mtdblock3, sector 2
+SQUASHFS error: squashfs_read_data failed to read block 0x6e
+
+After increasing the tolerance for the timeout to 200ms I haven't seen
+these SPI transfer time outs any more.
+The Lantiq SPI driver in use here has an extra work queue in between,
+which gets triggered when the controller send the last word and the
+hardware FIFOs used for reading and writing are only 8 words long.
+
+Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+---
+ drivers/spi/spi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/spi/spi.c
++++ b/drivers/spi/spi.c
+@@ -1004,7 +1004,7 @@ static int spi_transfer_one_message(stru
+ ret = 0;
+ ms = 8LL * 1000LL * xfer->len;
+ do_div(ms, xfer->speed_hz);
+- ms += ms + 100; /* some tolerance */
++ ms += ms + 200; /* some tolerance */
+
+ if (ms > UINT_MAX)
+ ms = UINT_MAX;