All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa-dev@sang-engineering.com>
To: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Andrew Jackson <Andrew.Jackson@arm.com>,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] i2c: designware: fix rx fifo depth tracking
Date: Thu, 24 Nov 2016 16:18:47 +0100	[thread overview]
Message-ID: <20161124151847.GH4271@katana> (raw)
In-Reply-To: <E1c7p18-0000R6-4w@rmk-PC.armlinux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

On Fri, Nov 18, 2016 at 07:40:10PM +0000, Russell King wrote:
> When loading the TX fifo to receive bytes on the I2C bus, we incorrectly
> count the number of bytes:
> 
> 	rx_limit = dev->rx_fifo_depth - dw_readl(dev, DW_IC_RXFLR);
> 
> 	while (buf_len > 0 && tx_limit > 0 && rx_limit > 0) {
> 		if (rx_limit - dev->rx_outstanding <= 0)
> 			break;
> 		rx_limit--;
> 		dev->rx_outstanding++;
> 	}
> 
> DW_IC_RXFLR indicates how many bytes are available to be read in the
> FIFO, dev->rx_fifo_depth is the FIFO size, and dev->rx_outstanding is
> the number of bytes that we've requested to be read so far, but which
> have not been read.
> 
> Firstly, increasing dev->rx_outstanding and decreasing rx_limit and then
> comparing them results in each byte consuming "two" bytes in this
> tracking, so this is obviously wrong.
> 
> Secondly, the number of bytes that _could_ be received into the FIFO at
> any time is the number of bytes we have so far requested but not yet
> read from the FIFO - in other words dev->rx_outstanding.
> 
> So, in order to request enough bytes to fill the RX FIFO, we need to
> request dev->rx_fifo_depth - dev->rx_outstanding bytes.
> 
> Modifying the code thusly results in us reaching the maximum number of
> bytes outstanding each time we queue more "receive" operations, provided
> the transfer allows that to happen.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Applied to for-current, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: wsa-dev@sang-engineering.com (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] i2c: designware: fix rx fifo depth tracking
Date: Thu, 24 Nov 2016 16:18:47 +0100	[thread overview]
Message-ID: <20161124151847.GH4271@katana> (raw)
In-Reply-To: <E1c7p18-0000R6-4w@rmk-PC.armlinux.org.uk>

On Fri, Nov 18, 2016 at 07:40:10PM +0000, Russell King wrote:
> When loading the TX fifo to receive bytes on the I2C bus, we incorrectly
> count the number of bytes:
> 
> 	rx_limit = dev->rx_fifo_depth - dw_readl(dev, DW_IC_RXFLR);
> 
> 	while (buf_len > 0 && tx_limit > 0 && rx_limit > 0) {
> 		if (rx_limit - dev->rx_outstanding <= 0)
> 			break;
> 		rx_limit--;
> 		dev->rx_outstanding++;
> 	}
> 
> DW_IC_RXFLR indicates how many bytes are available to be read in the
> FIFO, dev->rx_fifo_depth is the FIFO size, and dev->rx_outstanding is
> the number of bytes that we've requested to be read so far, but which
> have not been read.
> 
> Firstly, increasing dev->rx_outstanding and decreasing rx_limit and then
> comparing them results in each byte consuming "two" bytes in this
> tracking, so this is obviously wrong.
> 
> Secondly, the number of bytes that _could_ be received into the FIFO at
> any time is the number of bytes we have so far requested but not yet
> read from the FIFO - in other words dev->rx_outstanding.
> 
> So, in order to request enough bytes to fill the RX FIFO, we need to
> request dev->rx_fifo_depth - dev->rx_outstanding bytes.
> 
> Modifying the code thusly results in us reaching the maximum number of
> bytes outstanding each time we queue more "receive" operations, provided
> the transfer allows that to happen.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

Applied to for-current, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161124/cd1f3cc5/attachment.sig>

  parent reply	other threads:[~2016-11-24 15:18 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-18 19:35 [BUG] i2c-designware silently fails on long transfers Russell King - ARM Linux
2016-11-18 19:35 ` Russell King - ARM Linux
2016-11-18 19:40 ` [PATCH 1/2] i2c: designware: report short transfers Russell King
2016-11-18 19:40   ` Russell King
2016-11-21 10:32   ` Mika Westerberg
2016-11-21 10:32     ` Mika Westerberg
2016-11-23 14:13     ` Jarkko Nikula
2016-11-23 14:13       ` Jarkko Nikula
2016-11-24 15:18   ` Wolfram Sang
2016-11-24 15:18     ` Wolfram Sang
2016-11-18 19:40 ` [PATCH 2/2] i2c: designware: fix rx fifo depth tracking Russell King
2016-11-18 19:40   ` Russell King
2016-11-21 10:40   ` Mika Westerberg
2016-11-21 10:40     ` Mika Westerberg
2016-11-23 14:13     ` Jarkko Nikula
2016-11-23 14:13       ` Jarkko Nikula
2016-11-24 15:18   ` Wolfram Sang [this message]
2016-11-24 15:18     ` Wolfram Sang
2016-11-21 10:29 ` [BUG] i2c-designware silently fails on long transfers Mika Westerberg
2016-11-21 10:29   ` Mika Westerberg
2016-11-21 10:43   ` Russell King - ARM Linux
2016-11-21 10:43     ` Russell King - ARM Linux
2016-11-21 11:09     ` Mika Westerberg
2016-11-21 11:09       ` Mika Westerberg
2016-11-21 11:21     ` Liviu Dudau
2016-11-21 11:21       ` Liviu Dudau
2016-11-21 11:36       ` Russell King - ARM Linux
2016-11-21 11:36         ` Russell King - ARM Linux
2016-11-21 12:11     ` Robin Murphy
2016-11-21 12:11       ` Robin Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161124151847.GH4271@katana \
    --to=wsa-dev@sang-engineering.com \
    --cc=Andrew.Jackson@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rmk+kernel@armlinux.org.uk \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.