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 7C949C25B75 for ; Fri, 31 May 2024 14:45:38 +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=kVLGLJyYSa69Cau6RCTIPmZ5Cs7R4qSKjb7Z1HAiEyY=; b=eIdKNp6wAA73BF rdIHlsO5eHQFbEE2qpdrIwDnb1flRc80CaITEcV5pNyqQ7iqq21G8EDPLd1ehrCha6gpSY4GACgLW zdUNcLlqPLL+rQOlfbEQIiB3HlsW0LnxGWkxnSi4GZJdDlVkroN2TdmNeXT6bmkKv3oVWsqjDqqtV W2NxNiXi9EiIS3ly2ni+/aMrkCXWi8aW9IdN91DLF+ezF17DFLx1W3SkX3DCxFFicl2aVhCS9WUQu 2Hp/fsPRmH5etNDyNDC7riaQXeso/OIVatL9RnogQx4MrWx+xEgt2IzlKH4m0Zh14QIwc7NBwwd0A g3dgLpHhU6HeyUiuODfw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sD3VU-0000000AYTG-0EXY; Fri, 31 May 2024 14:45:24 +0000 Received: from mgamail.intel.com ([192.198.163.14]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sD3VR-0000000AYSR-1SAE for linux-arm-kernel@lists.infradead.org; Fri, 31 May 2024 14:45:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1717166721; x=1748702721; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=EIrwrMgP84onPe3hHLgvihCbppR9nSwhvh1a+A539DY=; b=jcFWpNXXmRrv4i+EekeA5O1pymvaEHqxRKy0k17HiGiyKVc3BGMI79+P YnRKl+z2OowYxqSQum0yMHMvNIQX7vFQk7lPkMlmT0Xe8sqgYh5AndXih hp19iBqfJkCLMXz2DxuPGfUD3BC1SQDUNe500kUk7jNPqYNUiQWncEJhM Hf0xUH+TXjSplLJ2OOaIhrgHm2y9ypTl7JboI30bSDHlHvqelpY5fn5zR V3ex0uTFKlTXaWx1i5eB+/e0qIISifw7bBi6bMH8iaxMOA4R2SSFi0Ifj U1i1s4ZQHK2aC5OsZj6H+o3WvFJibnKCjeAYiaiiAhgL9pXJkkxwHZsVB g==; X-CSE-ConnectionGUID: TnEjUNypQE+PJ9bR2FZcSw== X-CSE-MsgGUID: 1X12N8ohRHOlx9zBogbxuA== X-IronPort-AV: E=McAfee;i="6600,9927,11088"; a="13939050" X-IronPort-AV: E=Sophos;i="6.08,204,1712646000"; d="scan'208";a="13939050" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 07:45:19 -0700 X-CSE-ConnectionGUID: AF/eqOPGQtC4ibKbWQSFkQ== X-CSE-MsgGUID: OrRQBb5xQYCHfCfMLf2tzQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,204,1712646000"; d="scan'208";a="67030268" Received: from smile.fi.intel.com ([10.237.72.54]) by orviesa002.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2024 07:45:14 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1sD3VG-0000000CUn1-45IS; Fri, 31 May 2024 17:45:10 +0300 Date: Fri, 31 May 2024 17:45:10 +0300 From: Andy Shevchenko To: Stefan Eichenberger Cc: o.rempel@pengutronix.de, kernel@pengutronix.de, andi.shyti@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com, jic23@kernel.org, lars@metafoo.de, nuno.sa@analog.com, u.kleine-koenig@pengutronix.de, marcelo.schmitt@analog.com, gnstark@salutedevices.com, francesco.dolcini@toradex.com, linux-i2c@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org, Stefan Eichenberger Subject: Re: [RFC PATCH] i2c: imx: avoid rescheduling when waiting for bus not busy Message-ID: References: <20240531142437.74831-1-eichest@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240531142437.74831-1-eichest@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240531_074521_422342_C2C81577 X-CRM114-Status: GOOD ( 23.96 ) 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, May 31, 2024 at 04:24:37PM +0200, Stefan Eichenberger wrote: > From: Stefan Eichenberger > > On our i.MX8M Mini based module we have an ADS1015 I2C ADC connected to > the I2C bus. The ADS1015 I2C ADC will timeout after 25ms when the I2C > bus is idle. The imx i2c driver will call schedule when waiting for the > bus to become idle after switching to master mode. When the i2c > controller switches to master mode it pulls SCL and SDA low, if the > ADS1015 I2C ADC sees this for more than 25 ms without seeing SCL > clocking, it will timeout and ignore all signals until the next start > condition occurs (SCL and SDA low). This can occur when the system load > is high and schedule returns after more than 25 ms. > > This rfc tries to solve the problem by using a udelay for the first 10 > ms before calling schedule. This reduces the chance that we will > reschedule. However, it is still theoretically possible for the problem > to occur. To properly solve the problem, we would also need to disable > interrupts during the transfer. > > After some internal discussion, we see three possible solutions: > 1. Use udelay as shown in this rfc and also disable the interrupts > during the transfer. This would solve the problem but disable the > interrupts. Also, we would have to re-enable the interrupts if the > timeout is longer than 1ms (TBD). > 2. We use a retry mechanism in the ti-ads1015 driver. When we see a > timeout, we try again. > 3. We use the suggested solution and accept that there is an edge case > where the timeout can happen. > > There may be a better way to do this, which is why this is an RFC. ... > + /* > + * Avoid rescheduling in the first 10 ms to avoid > + * timeouts for SMBus like devices > + */ > + if (time_before(jiffies, orig_jiffies + msecs_to_jiffies(10))) > + udelay(10); > + else > + schedule(); Isn't there cond_resched() or so for such things? More info here: 494e46d08d35 ("airo: Replace in_atomic() usage.") -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel