From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752895AbbELHPm (ORCPT ); Tue, 12 May 2015 03:15:42 -0400 Received: from metis.ext.pengutronix.de ([92.198.50.35]:50656 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621AbbELHPj (ORCPT ); Tue, 12 May 2015 03:15:39 -0400 Date: Tue, 12 May 2015 09:15:06 +0200 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Doug Anderson Cc: Wolfram Sang , Addy Ke , Max Schwarz , Heiko Stuebner , Dmitry Torokhov , linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] i2c: rk3x: Increase wait timeout to 1 second Message-ID: <20150512071506.GW12671@pengutronix.de> References: <1431373468-18302-1-git-send-email-dianders@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1431373468-18302-1-git-send-email-dianders@chromium.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Acked-by: Uwe Kleine-König Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |