From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robin Murphy Subject: Re: [BUG] i2c-designware silently fails on long transfers Date: Mon, 21 Nov 2016 12:11:37 +0000 Message-ID: <272dcf6f-ffa5-4ddd-7597-d9a18d210e7a@arm.com> References: <20161118193542.GO1041@n2100.armlinux.org.uk> <20161121102901.GF1446@lahna.fi.intel.com> <20161121104329.GB1041@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: Received: from foss.arm.com ([217.140.101.70]:58374 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754382AbcKUMLk (ORCPT ); Mon, 21 Nov 2016 07:11:40 -0500 In-Reply-To: <20161121104329.GB1041@n2100.armlinux.org.uk> Sender: linux-i2c-owner@vger.kernel.org List-Id: linux-i2c@vger.kernel.org To: Russell King - ARM Linux , Mika Westerberg Cc: Wolfram Sang , Andrew Jackson , Liviu Dudau , Jarkko Nikula , linux-i2c@vger.kernel.org, Andy Shevchenko , linux-arm-kernel@lists.infradead.org On 21/11/16 10:43, Russell King - ARM Linux wrote: > On Mon, Nov 21, 2016 at 12:29:01PM +0200, Mika Westerberg wrote: >> On Fri, Nov 18, 2016 at 07:35:42PM +0000, Russell King - ARM Linux wrote: >>> Another mitigation would be to lower the I2C bus frequency on Juno from >>> 400kHz to 100kHz, so that there's 4x longer IRQ latency possible. >>> However, even that isn't going to be reliable - even going to 100kHz >>> isn't going to allow the above case to be solved - the interrupt is >>> delayed by around 2ms, and it takes about 1.4ms to send/receive 16 bytes >>> at 100kHz. (9 * 16 / (100*10^3)). >>> >>> So, I think all hope is lost for i2c-designware on Juno to cope with >>> reading the EDID from TDA998x reliably. >> >> :-( >> >> I wonder if we can get it work more reliably by using DMA (provided that >> there are DMA channels available for I2C in Juno)? That would allow the >> hardware to perform longer reads without relying on how fast the >> interrupt handler is able to empty the Rx FIFO. > > It would need to DMA to the Tx FIFO to keep it filled - it triggers the > stop condition when the Tx FIFO empties. From what I can see in the > driver, the Tx FIFO not only takes the data but also a "command" to tell > the hardware what to do. > > The Rx FIFO would also need DMA to avoid it overflowing due to high > interrupt latency. > > I don't know what state DMA is in on the Juno, or even whether it has > DMA - it has a PL330 DMA controller, but I see nothing in the DT files > making use of it. There's no DMA request wired up for I2C, unfortunately - only for the UARTs, I2S, FPFGA tile and trace unit. I recall Liviu did have a patch to lower the I2C clock as the mitigation you mention, which I thought had made it into mainline, but apparently not. Robin. From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Mon, 21 Nov 2016 12:11:37 +0000 Subject: [BUG] i2c-designware silently fails on long transfers In-Reply-To: <20161121104329.GB1041@n2100.armlinux.org.uk> References: <20161118193542.GO1041@n2100.armlinux.org.uk> <20161121102901.GF1446@lahna.fi.intel.com> <20161121104329.GB1041@n2100.armlinux.org.uk> Message-ID: <272dcf6f-ffa5-4ddd-7597-d9a18d210e7a@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 21/11/16 10:43, Russell King - ARM Linux wrote: > On Mon, Nov 21, 2016 at 12:29:01PM +0200, Mika Westerberg wrote: >> On Fri, Nov 18, 2016 at 07:35:42PM +0000, Russell King - ARM Linux wrote: >>> Another mitigation would be to lower the I2C bus frequency on Juno from >>> 400kHz to 100kHz, so that there's 4x longer IRQ latency possible. >>> However, even that isn't going to be reliable - even going to 100kHz >>> isn't going to allow the above case to be solved - the interrupt is >>> delayed by around 2ms, and it takes about 1.4ms to send/receive 16 bytes >>> at 100kHz. (9 * 16 / (100*10^3)). >>> >>> So, I think all hope is lost for i2c-designware on Juno to cope with >>> reading the EDID from TDA998x reliably. >> >> :-( >> >> I wonder if we can get it work more reliably by using DMA (provided that >> there are DMA channels available for I2C in Juno)? That would allow the >> hardware to perform longer reads without relying on how fast the >> interrupt handler is able to empty the Rx FIFO. > > It would need to DMA to the Tx FIFO to keep it filled - it triggers the > stop condition when the Tx FIFO empties. From what I can see in the > driver, the Tx FIFO not only takes the data but also a "command" to tell > the hardware what to do. > > The Rx FIFO would also need DMA to avoid it overflowing due to high > interrupt latency. > > I don't know what state DMA is in on the Juno, or even whether it has > DMA - it has a PL330 DMA controller, but I see nothing in the DT files > making use of it. There's no DMA request wired up for I2C, unfortunately - only for the UARTs, I2S, FPFGA tile and trace unit. I recall Liviu did have a patch to lower the I2C clock as the mitigation you mention, which I thought had made it into mainline, but apparently not. Robin.