All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Stigge <stigge-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
To: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: vitalywool-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org,
	ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
	grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	kevin.wells-3arQi8VN3Tc@public.gmane.org,
	srinivas.bakki-3arQi8VN3Tc@public.gmane.org,
	aletes.xgr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Subject: Re: [PATCH RESEND 2/2] i2c: pnx: Fix read transactions of >= 2 bytes
Date: Sun, 19 Aug 2012 10:45:20 +0200	[thread overview]
Message-ID: <5030A7A0.3080308@antcom.de> (raw)
In-Reply-To: <20120818095212.GC24812-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Hi,

On 18/08/12 11:52, Wolfram Sang wrote:
> On Wed, Aug 08, 2012 at 09:42:32AM +0200, Roland Stigge wrote:
>> On transactions with n>=2 bytes, the controller actually wrongly
>> clocks in n+1 bytes. This is caused by the (wrong) assumption
>> that RFE in the Status Register is 1 iff there is no byte already
>> ordered (via a dummy TX byte). This lead to the implementation of
>> synchronized byte ordering, e.g.:
>> 
>> Dummy-TX - RX - Dummy-TX - RX - ...
>> 
>> But since RFE actually stays high after some Dummy-TX, it rather
>> looks like:
>> 
>> Dummy-TX - Dummy-TX - RX - Dummy-TX - RX - (RX)
>> 
>> The last RX byte is clocked in by the bus controller, but ignored
>> by the kernel when filling the userspace buffer.
>> 
>> This patch fixes the issue by asking for RX via Dummy-TX
>> asynchronously. Introducing a separate counter for TX bytes.
>> 
>> Signed-off-by: Roland Stigge <stigge-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
>> 
>> --- Applies to v3.6-rc1
>> 
>> This patch for i2c-pnx affects PNX4008 and LPC32xx (and LPC31xx,
>> not yet in mainline). Can you please test?
>> 
>> Thanks in advance!
> 
> I assume you checked this on LPC32xx?

Yes.

The bug surfaced when we debugged unexpected behaviour with I2C
clients. A colleague noticed that sometimes, there were more bytes
transferred than expected, confusing some I2C clients.

The patch fixes exactly that.

Thanks,

Roland

WARNING: multiple messages have this Message-ID (diff)
From: Roland Stigge <stigge@antcom.de>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: vitalywool@gmail.com, khali@linux-fr.org, ben-linux@fluff.org,
	grant.likely@secretlab.ca, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org, kevin.wells@nxp.com,
	srinivas.bakki@nxp.com, aletes.xgr@gmail.com, jonsmirl@gmail.com
Subject: Re: [PATCH RESEND 2/2] i2c: pnx: Fix read transactions of >= 2 bytes
Date: Sun, 19 Aug 2012 10:45:20 +0200	[thread overview]
Message-ID: <5030A7A0.3080308@antcom.de> (raw)
In-Reply-To: <20120818095212.GC24812@pengutronix.de>

Hi,

On 18/08/12 11:52, Wolfram Sang wrote:
> On Wed, Aug 08, 2012 at 09:42:32AM +0200, Roland Stigge wrote:
>> On transactions with n>=2 bytes, the controller actually wrongly
>> clocks in n+1 bytes. This is caused by the (wrong) assumption
>> that RFE in the Status Register is 1 iff there is no byte already
>> ordered (via a dummy TX byte). This lead to the implementation of
>> synchronized byte ordering, e.g.:
>> 
>> Dummy-TX - RX - Dummy-TX - RX - ...
>> 
>> But since RFE actually stays high after some Dummy-TX, it rather
>> looks like:
>> 
>> Dummy-TX - Dummy-TX - RX - Dummy-TX - RX - (RX)
>> 
>> The last RX byte is clocked in by the bus controller, but ignored
>> by the kernel when filling the userspace buffer.
>> 
>> This patch fixes the issue by asking for RX via Dummy-TX
>> asynchronously. Introducing a separate counter for TX bytes.
>> 
>> Signed-off-by: Roland Stigge <stigge@antcom.de>
>> 
>> --- Applies to v3.6-rc1
>> 
>> This patch for i2c-pnx affects PNX4008 and LPC32xx (and LPC31xx,
>> not yet in mainline). Can you please test?
>> 
>> Thanks in advance!
> 
> I assume you checked this on LPC32xx?

Yes.

The bug surfaced when we debugged unexpected behaviour with I2C
clients. A colleague noticed that sometimes, there were more bytes
transferred than expected, confusing some I2C clients.

The patch fixes exactly that.

Thanks,

Roland

  parent reply	other threads:[~2012-08-19  8:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-08  7:42 [PATCH RESEND 1/2] i2c: pnx: Fix bit definitions Roland Stigge
     [not found] ` <1344411752-23469-1-git-send-email-stigge-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-08-08  7:42   ` [PATCH RESEND 2/2] i2c: pnx: Fix read transactions of >= 2 bytes Roland Stigge
2012-08-08  7:42     ` Roland Stigge
     [not found]     ` <1344411752-23469-2-git-send-email-stigge-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-08-18  9:52       ` Wolfram Sang
2012-08-18  9:52         ` Wolfram Sang
     [not found]         ` <20120818095212.GC24812-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-08-19  8:45           ` Roland Stigge [this message]
2012-08-19  8:45             ` Roland Stigge
2012-08-18  9:51   ` [PATCH RESEND 1/2] i2c: pnx: Fix bit definitions Wolfram Sang
2012-08-18  9:51     ` Wolfram Sang
     [not found]     ` <20120818095108.GB24812-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-08-19  8:47       ` Roland Stigge
2012-08-19  8:47         ` Roland Stigge
     [not found]         ` <5030A81E.5090508-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-08-20 16:26           ` Kevin Wells
2012-08-20 16:26             ` Kevin Wells
     [not found]             ` <083DF309106F364B939360100EC290F823A0354A3D-SIPbe8o7cfX8DdpCu65jn8FrZmdRls4ZQQ4Iyu8u01E@public.gmane.org>
2012-08-20 16:47               ` Roland Stigge
2012-08-20 16:47                 ` Roland Stigge
2012-08-20 16:47                 ` Roland Stigge
     [not found]                 ` <50326A3E.9070607-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-08-20 19:49                   ` Arnd Bergmann
2012-08-20 19:49                     ` Arnd Bergmann
2012-08-20 19:49                     ` Arnd Bergmann
2012-08-20 17:55               ` Wolfram Sang
2012-08-20 17:55                 ` Wolfram Sang
2012-08-20 20:47                 ` Roland Stigge
     [not found]                 ` <20120820175527.GA9169-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-09-03 20:16                   ` Roland Stigge
2012-09-03 20:16                     ` Roland Stigge
     [not found]                     ` <50451016.7010608-uj/7R2tJ6VmzQB+pC5nmwQ@public.gmane.org>
2012-09-04  9:20                       ` Wolfram Sang
2012-09-04  9:20                         ` Wolfram Sang

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=5030A7A0.3080308@antcom.de \
    --to=stigge-uj/7r2tj6vmzqb+pc5nmwq@public.gmane.org \
    --cc=aletes.xgr-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=jonsmirl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=kevin.wells-3arQi8VN3Tc@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=srinivas.bakki-3arQi8VN3Tc@public.gmane.org \
    --cc=vitalywool-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    /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.