[lkml]   [2015]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2] i2c: rk3x: Increase wait timeout to 1 second
On Mon, May 11, 2015 at 12:44:28PM -0700, Doug Anderson wrote:
> 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 <>
> Tested-by: Caesar Wang <>

Applied to for-next, thanks!

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2015-05-12 15:41    [W:0.038 / U:13.648 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site