On Fri, Dec 22, 2017 at 10:47:16PM +0100, Jan Kundrát wrote: > "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@xxxxxxxxx> Acked-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |
