From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1E59CC4167B for ; Fri, 30 Dec 2022 18:54:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cBbbpe4AJwznmekHDCXNe1jXDahu6vze6+gaDzCB3M8=; b=KOQOjIcIqDM5Ts PfagjOywm1hrRMP5tCMCOOE4h5UfJpPYRK686dZYShEDar0jzxTYedzA1NhFdj+VtO9L4gi9nxBnY tLogr5v8xsX7xOIrwx00df+9kui3HgwbwI26F9w/I5lDunA7FOFVm0OxXBSSiVNvPJ2IRZxCT5jzs lmevieVHD40Q118DWbv6/IiuUwEkoWvUA2+DpfjvtNCw+XbjWQFdZe1fQehaGjUHveG+2Pz+WlhDG FwK9Pln/qu5YbehnxtenZLuSPHb6y9sK+/En0rB3cj+xwdiAn0z4+N294RtnHvYig9MkfZe1fEIDJ Wcm/UQN7ObZ5bRMU7rHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pBKVW-00COLW-Va; Fri, 30 Dec 2022 18:53:32 +0000 Received: from smtp-out-06.comm2000.it ([212.97.32.74]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pBItX-00BP40-5u for linux-arm-kernel@lists.infradead.org; Fri, 30 Dec 2022 17:10:13 +0000 Received: from francesco-nb.int.toradex.com (93-49-2-63.ip317.fastwebnet.it [93.49.2.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: francesco@dolcini.it) by smtp-out-06.comm2000.it (Postfix) with ESMTPSA id E200E561636; Fri, 30 Dec 2022 18:10:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mailserver.it; s=mailsrv; t=1672420207; bh=CwPdwECEa0lZNbWx3u+AEjaZwD0ypB8MrNfUb6Wyo5s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=1Zm7EhgCaNt3T60FHS5zJkYJs4HxKkkhT/o4YWTxIJwhFfFduky6yrFxgxU8TueY+ 9pduKkFVBjm0JgSo4xILrpcy3KETkGY6PyP3B6aFc9TXH8dmQUY3MV62uZ0DXrRVAm +i1CNyd23RgVVxVcrWae6IkmFBAdELPFC6n+r0Uk8wnIvBOys0CobJuPQ8MAorCgFL CFcojwGlzuTmennb6Ro+APlaQFUapB4LkeAJ+qDb3JOZ+STzjWn5W7/N2vVKRNTM1T /86fEkXkCdg6OMgwY4IpBv62gMKNOW/Lk0ZkZugBs3kk/rnlBLKD/Nn4N0mD/OsRc1 tj46nN5ZvrKRg== Date: Fri, 30 Dec 2022 18:09:57 +0100 From: Francesco Dolcini To: Oleksij Rempel Cc: Primoz Fiser , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , linux-kernel@vger.kernel.org, Shawn Guo , Sascha Hauer , upstream@lists.phytec.de, Marco Felsch , Oleksij Rempel , NXP Linux Team , Pengutronix Kernel Team , Fabio Estevam , linux-arm-kernel@lists.infradead.org, linux-i2c@vger.kernel.org, francesco.dolcini@toradex.com, wsa@kernel.org, Francesco Dolcini Subject: Re: [PATCH] i2c: imx: increase retries on arbitration loss Message-ID: References: <20221216094518.bevkg5buzu7iybfh@pengutronix.de> <20221216110227.GA12327@pengutronix.de> <20221216111308.wckibotr5d3q6ree@pengutronix.de> <5c2e0531-e7c3-1b37-35ed-c8e9795a0d18@norik.com> <41991ce2-3e88-5afc-6def-6e718d624768@norik.com> <20221230161209.GA14776@pengutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221230_091011_698243_AC24CA96 X-CRM114-Status: GOOD ( 50.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Dec 30, 2022 at 05:47:42PM +0100, Francesco Dolcini wrote: > On Fri, Dec 30, 2022 at 05:12:09PM +0100, Oleksij Rempel wrote: > > On Fri, Dec 30, 2022 at 03:40:58PM +0100, Francesco Dolcini wrote: > > > +Wolfram > > > > > > On Wed, Dec 28, 2022 at 09:01:46AM +0100, Primoz Fiser wrote: > > > > On 16. 12. 22 13:51, Francesco Dolcini wrote: > > > > > On Fri, Dec 16, 2022 at 01:23:29PM +0100, Primoz Fiser wrote: > > > > > > The only solid point in the thread seems to be that in that case we are not > > > > > > covering up the potential i2c hardware issues? > > > > > > > > > > I believe that in this case we should just have a warning in the kernel. > > > > > The retry potentially work-around a transient issue and we do not hide any hardware > > > > > issue at the same time. It seems an easy win-win solution. > > > > > > > > I would agree about throwing a warning message in retry case. > > > > > > > > Not sure how would it affect other i2c bus drivers using retries > 0. > > > > Retries might be pretty rare with i2c-imx but some other drivers set this to > > > > 5 for example. At least using _ratelimited printk is a must using this > > > > approach. > > > > > > Wolfram, Uwe, Oleksij > > > > > > Would it be acceptable to have a warning when we have I2C retries, and > > > with that in place enabling retries on the imx driver? > > > > > > It exists hardware that requires this to work correctly, > > > > Well, this is persistent confusion in this monolog. It will not make it > > correctly. > > > > > and at a > > > minimum setting the retry count from user space is not going to solve > > > potential issues during initial driver probe. > > > > I assume it is not clear from programmer point of view. Lets try other way: > > > > - The I2C slave could not correctly interpret the data on SDA because the SDA > > high or low-level voltages do not reach its appropriate input > > thresholds. > > > > This means: > > > > You have this: > > > > /-\ /-\ ----- 2.5Vcc > > ___/ \__/ \___ > > > > Instead of this: > > > > /-\ /-\ ----- 3.3Vcc > > / \ / \ > > ___/ \__/ \___ > > > > This is bad, because master or slave will not be able to interpret the pick level > > correctly. It may see some times 0 instead of 1. This means, what ever we are > > writing we are to the slave or reading from the slave is potentially corrupt > > and only __sometimes__ the master was able to detect it. > > > > - The I2C slave missed an SCL cycle because the SCL high or low-level voltages > > do not reach its appropriate input thresholds. > > > > This means, the bus frequency is too high for current configured or physical PCB > > designed. So, you will have different kind of corruptions and some times they > > will be detected. > > > > - The I2C slave accidently interpreted a spike etc. as an SCL cycle. > > > > This means the noise level is to high. The driver strange should be increased > > or PCB redesign should be made. May be there are more options. If not done, > > data corruption can be expected. > > > > None of this issue can be "fixed" by retries or made more "robust". > > Doing more retries means: we do what ever we do until the system was not able to > > detect the error. > > Hello Oleksij, > thanks for the detailed explanation, appreciated. > > Given that is it correct that the i2c imx driver return EAGAIN in such a > case (arbitration error)? You made it crystal clear that there is no > such thing as try again for this error, I would be inclined to prepare a > patch to fix this. > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c > index cf5bacf3a488..a2a581c8ae07 100644 > --- a/drivers/i2c/busses/i2c-imx.c > +++ b/drivers/i2c/busses/i2c-imx.c > @@ -492,7 +492,7 @@ static int i2c_imx_bus_busy(struct imx_i2c_struct *i2c_imx, int for_busy, bool a > /* check for arbitration lost */ > if (temp & I2SR_IAL) { > i2c_imx_clear_irq(i2c_imx, I2SR_IAL); > - return -EAGAIN; > + return -EIO; > } > > if (for_busy && (temp & I2SR_IBB)) { > Just a small addition, the tegra i2c driver is interesting. It returns EAGAIN only when an arbitration error is detected on multi master node, otherwise it tries the bus recovery procedure. /* start recovery upon arbitration loss in single master mode */ if (i2c_dev->msg_err == I2C_ERR_ARBITRATION_LOST) { if (!i2c_dev->multimaster_mode) return i2c_recover_bus(&i2c_dev->adapter); return -EAGAIN; } Francesco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel