All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads
Date: Thu, 26 Jun 2014 10:47:55 -0600	[thread overview]
Message-ID: <53AC4EBB.8030108@wwwdotorg.org> (raw)
In-Reply-To: <OFE92950D0.D76350E7-ONC1257D03.002C9777-C1257D03.002D025A@transmode.se>

On 06/26/2014 02:11 AM, Joakim Tjernlund wrote:
>> From: Stephen Warren <swarren@wwwdotorg.org>
>> To: u-boot at lists.denx.de, Heiko Schocher <hs@denx.de>, 
>> Cc: Stephen Warren <swarren@nvidia.com>, Tom Warren <twarren@nvidia.com>
>> Date: 2014/06/25 19:05
>> Subject: [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads
>> Sent by: u-boot-bounces at lists.denx.de
>>
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> I2C read transactions are typically implemented as follows:
>>
>> START(write) address REPEATED_START(read) data... STOP
>>
>> However, Tegra's I2C driver currently implements reads as follows:
>>
>> START(write) address STOP START(read) data... STOP
>>
>> This sequence confuses at least the AS3722 PMIC on the Jetson TK1 board,
>> leading to corrupted read data in some cases. Fix the driver to chain
>> the transactions together using repeated starts to solve this.
> 
> While I agree to use Repeated START I just wanted to share this:
> A common reason for STOP START(read) sequence not working sometimes is 
> that
> the driver initializes STOP but does not wait for the STOP to complete
> before issuing a START.

I don't believe that's the case here, since all this patch does is set a
flag to indicate whether the write transaction (to set the intra-chip
register address) generates STOP or REPEATED_START at the end. If the
code or HW wasn't waiting for the STOP to complete, I see no reason it
would wait for the REPEATED_START to complete either, so I think the
subsequent register read transaction would be corrupted in either case.

There's certainly code in tegra_i2c.c:wait_for_transfer_complete() to
poll until each transaction completes before starting the next, and
there's even error handling to detect any problems there:-)

  reply	other threads:[~2014-06-26 16:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 16:57 [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads Stephen Warren
2014-06-25 16:57 ` [U-Boot] [PATCH 2/3] i2c: tegra: write clean data to TX FIFO Stephen Warren
2014-06-25 23:37   ` Yen Lin
2014-06-25 23:42   ` Yen Lin
2014-06-25 16:57 ` [U-Boot] [PATCH 3/3] i2c: tegra: dump alen in debug statements Stephen Warren
2014-06-25 23:40   ` Yen Lin
2014-06-25 23:36 ` [U-Boot] [PATCH 1/3] i2c: tegra: use repeated start for reads Yen Lin
2014-06-26  2:12 ` Simon Glass
2014-06-26  4:09   ` Stephen Warren
2014-06-26  8:11 ` Joakim Tjernlund
2014-06-26 16:47   ` Stephen Warren [this message]
2014-06-26 19:11     ` Joakim Tjernlund
2014-06-26 19:18       ` Stephen Warren
2014-06-26 19:24         ` Stephen Warren
2014-06-26 20:01           ` Joakim Tjernlund
2014-06-26 22:54             ` Stephen Warren
2014-06-26 19:40         ` Joakim Tjernlund
2014-07-02 18:37 ` Stephen Warren
2014-07-03  4:34   ` Heiko Schocher
2014-07-21 15:14     ` Stephen Warren

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=53AC4EBB.8030108@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=u-boot@lists.denx.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.