Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753234AbbEADmv (ORCPT ); Thu, 30 Apr 2015 23:42:51 -0400 Received: from m50-135.163.com ([123.125.50.135]:39084 "EHLO m50-135.163.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077AbbEADms (ORCPT ); Thu, 30 Apr 2015 23:42:48 -0400 Message-ID: <5542F5B5.9000206@163.com> Date: Fri, 01 May 2015 11:40:37 +0800 From: Caesar Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Doug Anderson , Wolfram Sang CC: Addy Ke , Dmitry Torokhov , Heiko Stuebner , Max Schwarz , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] i2c: rk3x: Increase wait timeout to 1 second References: <1430430247-9632-1-git-send-email-dianders@chromium.org> In-Reply-To: <1430430247-9632-1-git-send-email-dianders@chromium.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: D9GowABnIG+19UJVGJHLBQ--.383S3 X-Coremail-Antispam: 1Uf129KBjvJXoW7Kr1DuFW3uw18tr1DGFW8Crg_yoW8Gr4Upr 47Ka92krn0qFy2g3Z7JF13XryFqay8W3yjgr9xKrykuFs8J3Z7Cwsrtay5uFyv9ryjkr42 q3yqqa43CF4jy37anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jxa93UUUUU= X-Originating-IP: [110.90.45.118] X-CM-SenderInfo: 5vdv3yhhz03qqrwthudrp/1tbiShjslVO-tImOAAAAs0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1617 Lines: 49 在 2015年05月01日 05:44, Doug Anderson 写道: > While it's not sensible for an i2c command to _actually_ need more > than 200ms to complete, let's increase the timeout anyway. Why? 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. > > 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 > --- > drivers/i2c/busses/i2c-rk3x.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c > index 019d542..72e97e30 100644 > --- a/drivers/i2c/busses/i2c-rk3x.c > +++ b/drivers/i2c/busses/i2c-rk3x.c > @@ -72,7 +72,7 @@ enum { > #define REG_INT_ALL 0x7f > > /* Constants */ > -#define WAIT_TIMEOUT 200 /* ms */ > +#define WAIT_TIMEOUT 1000 /* ms */ Yeah, verified on veyron device. Tested-by: Caesar Wang Thanks. Caesar > #define DEFAULT_SCL_RATE (100 * 1000) /* Hz */ > > enum rk3x_i2c_state { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/