From: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: max.schwarz-BGeptl67XyCzQB+pC5nmwQ@public.gmane.org,
heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
hl-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
cyw-TNX95d0MmH7DzftRWevZcw@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Applied to for-next, thanks!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
WARNING: multiple messages have this Message-ID (diff)
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>
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: Doug Anderson <dianders@chromium.org>
Cc: max.schwarz@online.de, heiko@sntech.de,
u.kleine-koenig@pengutronix.de, addy.ke@rock-chips.com,
hl@rock-chips.com, cyw@rock-chips.com, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-i2c@vger.kernel.org
Subject: Re: [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>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
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!
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-01-13 11:47 UTC|newest]
Thread overview: 5+ 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
2014-12-18 17:44 ` Doug Anderson
[not found] ` <1418924647-23795-1-git-send-email-dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2015-01-13 11:47 ` Wolfram Sang [this message]
2015-01-13 11:47 ` Wolfram Sang
2015-01-13 11:47 ` 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=20150113114714.GD7660@katana \
--to=wsa-z923lk4zbo2bacvfa/9k2g@public.gmane.org \
--cc=addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=cyw-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=hl-TNX95d0MmH7DzftRWevZcw@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=max.schwarz-BGeptl67XyCzQB+pC5nmwQ@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=u.kleine-koenig-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.