#include #include #include #include #include #include "corking.h" #include "die.h" void set_udp_cork(int fd) { int ret, state = 1; ret = setsockopt(fd, IPPROTO_UDP, UDP_CORK, &state, sizeof(state)); if (unlikely(ret)) panic("Cannot cork UDP socket!\n"); } void set_udp_uncork(int fd) { int ret, state = 0; ret = setsockopt(fd, IPPROTO_UDP, UDP_CORK, &state, sizeof(state)); if (unlikely(ret)) panic("Cannot uncork UDP socket!\n"); } void set_tcp_cork(int fd) { int ret, state = 1; ret = setsockopt(fd, IPPROTO_TCP, TCP_CORK, &state, sizeof(state)); if (unlikely(ret)) panic("Cannot cork TCP socket!\n"); } void set_tcp_uncork(int fd) { int ret, state = 0; ret = setsockopt(fd, IPPROTO_TCP, TCP_CORK, &state, sizeof(state)); if (unlikely(ret)) panic("Cannot uncork TCP socket!\n"); } void set_sock_cork(int fd, bool is_udp) { if (is_udp) set_udp_cork(fd); else set_tcp_cork(fd); } void set_sock_uncork(int fd, bool is_udp) { if (is_udp) set_udp_uncork(fd); else set_tcp_uncork(fd); } tion value='emaclite-cleanup'>emaclite-cleanup net-next plumbingsTobias Klauser
summaryrefslogtreecommitdiff
path: root/Documentation/i2c
diff options
context:
space:
mode:
authorDaniel Kurtz <djkurtz@chromium.org>2016-10-07 18:55:47 +0800
committerMark Brown <broonie@kernel.org>2016-10-26 12:35:17 +0100
commit8244bd3ab405a1268223a282b32d28031f7e16fe (patch)
treee2e100f44d7c548d2bc436612751a1f0b26590e7 /Documentation/i2c
parent1001354ca34179f3db924eb66672442a173147dc (diff)
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 'Documentation/i2c')