diff options
author | Daniel Kurtz <djkurtz@chromium.org> | 2016-10-07 18:55:47 +0800 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2016-10-26 12:35:17 +0100 |
commit | 8244bd3ab405a1268223a282b32d28031f7e16fe (patch) | |
tree | e2e100f44d7c548d2bc436612751a1f0b26590e7 /drivers/spi/spi-fsl-dspi.c | |
parent | 1001354ca34179f3db924eb66672442a173147dc (diff) | |
download | op-kernel-dev-8244bd3ab405a1268223a282b32d28031f7e16fe.zip op-kernel-dev-8244bd3ab405a1268223a282b32d28031f7e16fe.tar.gz |
spi: change post transfer udelay() to usleep_range() for long delays
The spi_transfer parameter delay_usecs allows specifying a time to wait
after transferring a spi message. This wait can be quite long - some
devices, such as some Chrome OS ECs, require as much as 2000 usecs after
a SPI transaction, before it can respond.
(cf: arch/arm64/boot/dts/nvidia/tegra132-norrin.dts:
google,cros-ec-spi-msg-delay = <2000>
)
Blocking a CPU for 2 msecs in a busy loop like this doesn't seem very
friendly to other processes, so change the blocking delay to a sleep
to allow other things to use this CPU (or so it can sleep).
This should be safe to do, because:
(a) A post-transaction delay like this is always specified as a minimum
wait time
(b) A delay here is most likely not very time sensitive, as it occurs
after all data has been transferred
(c) This delay occurs in a non-critical section of the spi worker thread
so where it is safe to sleep.
Two caveats:
1) To avoid penalizing short delays, still use udelay for delays < 10us.
2) usleep_range() very often picks the upper bound, an upper bounds 10%
should be plenty.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'drivers/spi/spi-fsl-dspi.c')
0 files changed, 0 insertions, 0 deletions