From: Daniel Kurtz Date: Fri, 7 Oct 2016 10:55:47 +0000 (+0800) Subject: spi: change post transfer udelay() to usleep_range() for long delays X-Git-Tag: v4.10-rc5~13^2~7^2 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=8244bd3ab405a1268223a282b32d28031f7e16fe;p=platform%2Fkernel%2Flinux-exynos.git 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 Signed-off-by: Mark Brown --- diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 5787b72..42f3e1c 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1034,8 +1034,14 @@ static int spi_transfer_one_message(struct spi_master *master, if (msg->status != -EINPROGRESS) goto out; - if (xfer->delay_usecs) - udelay(xfer->delay_usecs); + if (xfer->delay_usecs) { + u16 us = xfer->delay_usecs; + + if (us <= 10) + udelay(us); + else + usleep_range(us, us + DIV_ROUND_UP(us, 10)); + } if (xfer->cs_change) { if (list_is_last(&xfer->transfer_list,