summaryrefslogtreecommitdiffstats
path: root/block/sed-opal.c
diff options
context:
space:
mode:
authorJan Kundrát <jan.kundrat@cesnet.cz>2017-12-22 22:47:16 +0100
committerWolfram Sang <wsa@the-dreams.de>2018-01-04 01:02:55 +0100
commitf11a04464ae57e8db1bb7634547842b43e36a898 (patch)
tree0759e0b693700075bf17546dc40d68a31993c8d1 /block/sed-opal.c
parentf6762cedbef91ad1da338538efa811856a717d57 (diff)
downloadtalos-op-linux-f11a04464ae57e8db1bb7634547842b43e36a898.tar.gz
talos-op-linux-f11a04464ae57e8db1bb7634547842b43e36a898.zip
i2c: gpio: Enable working over slow can_sleep GPIOs
"Slow" GPIOs (usually those connected over an SPI or an I2C bus) are, well, slow in their operation. It is generally a good idea to avoid using them for time-critical operation, but sometimes the hardware just sucks, and the software has to cope. In addition to that, the I2C bus itself does not actually define any strict timing limits; the bus is free to go all the way down to DC. The timeouts (and therefore the slowest acceptable frequency) are present only in SMBus. The `can_sleep` is IMHO a wrong concept to use here. My SPI-to-quad-UART chip (MAX14830) is connected via a 26MHz SPI bus, and it happily drives SCL at 200kHz (5µs pulses) during my benchmarks. That's faster than the maximal allowed speed of the traditional I2C. The previous version of this code did not really block operation over slow GPIO pins, anyway. Instead, it just resorted to printing a warning with a backtrace each time a GPIO pin was accessed, thereby slowing things down even more. Finally, it's not just me. A similar patch was originally submitted in 2015 [1]. [1] https://patchwork.ozlabs.org/patch/450956/ Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Diffstat (limited to 'block/sed-opal.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud