linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3] i2c: rk3x: Account for repeated start time requirement
Date: Tue, 13 Jan 2015 12:47:14 +0100	[thread overview]
Message-ID: <20150113114714.GD7660@katana> (raw)
In-Reply-To: <1418924647-23795-1-git-send-email-dianders@chromium.org>

On Thu, Dec 18, 2014 at 09:44:07AM -0800, Doug Anderson wrote:
> On Rockchip I2C the controller drops SDA low slightly too soon to meet
> the "repeated start" requirements.
> 
> From my own experimentation over a number of rates:
>  - controller appears to drop SDA at .875x (7/8) programmed clk high.
>  - controller appears to keep SCL high for 2x programmed clk high.
> 
> The first rule isn't enough to meet tSU;STA requirements in
> Standard-mode on the system I tested on.  The second rule is probably
> enough to meet tHD;STA requirements in nearly all cases (especially
> after accounting for the first), but it doesn't hurt to account for it
> anyway just in case.
> 
> Even though the repeated start requirement only need to be accounted
> for during a small part of the transfer, we'll adjust the timings for
> the whole transfer to meet it.  I believe that adjusting the timings
> in just the right place to switch things up for repeated start would
> require several extra interrupts and that doesn't seem terribly worth
> it.
> 
> With this change and worst case rise/fall times, I see 100kHz i2c
> going to ~85kHz.  With slightly optimized rise/fall (800ns / 50ns) I
> see i2c going to ~89kHz.  Fast-mode isn't affected much because
> tSU;STA is shorter relative to tHD;STA there.
> 
> As part of this change we needed to account for the SDA falling time.
> The specification indicates that this should be the same, but we'll
> follow Designware's lead and add a binding.  Note that we deviate from
> Designware and assign the default SDA falling time to be the same as
> the SCL falling time, which is incredibly likely.
> 
> Signed-off-by: Doug Anderson <dianders@chromium.org>

Applied to for-next, thanks!

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

      reply	other threads:[~2015-01-13 11:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 17:44 [PATCH v3] i2c: rk3x: Account for repeated start time requirement Doug Anderson
2015-01-13 11:47 ` Wolfram Sang [this message]

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=20150113114714.GD7660@katana \
    --to=wsa@the-dreams.de \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).