-
Doug Anderson authored
Although unlikely, it is remotely possible for an i2c command to need more than 200ms complete. Unlike smbus, i2c devices can clock stretch for an unspecified amount of time. The longest time I've seen specified for a device is 144ms (bq27541 battery gas), but one could imagine a device taking a bit slower. 1 second "ought to be enough for anyone." The above is not the only justifcation for going above 200ms for a timeout, though. It turns out that if you've got a large number of printks going out to a serial console, interrupts on a CPU can be disabled for hundreds of milliseconds. That's not a great situation to be in to start with (maybe we should put a cap in vprintk_emit()) but it's pretty annoying to start seeing unexplained i2c timeouts. Note that to understand why we can timeout when printk has interrupts disabled, you need to understand that on current Linux ARM kernels interrupts are routed to a single CPU in a multicore system. Thus, you can get: 1. CPU1 is running rk3x_i2c_xfer() 2. CPU0 calls vprintk_emit(), which disables all IRQs on CPU0. 3. I2C interrupt is ready but is set to only run on CPU0, where IRQs are disabled. 4. CPU1 timeout expires. I2C interrupt is still ready, but CPU0 is still sitting in the same vprintk_emit() 5. CPU1 sees that no interrupt happened in 200ms, so timeout. A normal system shouldn't see i2c timeouts anyway, so increasing the timeout should help people debugging without hurting other people excessively. Signed-off-by:
Doug Anderson <dianders@chromium.org> Tested-by:
Caesar Wang <wxt@rock-chips.com> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
4489750f