LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Addy Ke <addy.ke@rock-chips.com>
Cc: wsa@the-dreams.de, max.schwarz@online.de, heiko@sntech.de,
olof@lixom.net, dianders@chromium.org, robh+dt@kernel.org,
pawel.moll@arm.com, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, linux-i2c@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, cf@rock-chips.com,
xjq@rock-chips.com, huangtao@rock-chips.com, zyw@rock-chips.com,
yzq@rock-chips.com, hj@rock-chips.com, kever.yang@rock-chips.com,
hl@rock-chips.com, caesar.wang@rock-chips.com,
zhengsq@rock-chips.com
Subject: Re: [PATCH v4] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification
Date: Thu, 11 Dec 2014 08:47:38 +0100 [thread overview]
Message-ID: <20141211074738.GL13486@pengutronix.de> (raw)
In-Reply-To: <1418277650-25215-1-git-send-email-addy.ke@rock-chips.com>
Hello,
I like it now. There are only a few small nitpicks, not sure its worth
to respin if noone else has concerns. See below.
On Thu, Dec 11, 2014 at 02:00:49PM +0800, Addy Ke wrote:
> The number of clock cycles to be written into the CLKDIV register
> that determines the I2C clk high phase includes the rise time.
> So to meet the timing requirements defined in the I2C specification
> which defines the minimal time SCL has to be high, the rise time
> has to taken into account. The same applies to the low phase with
> falling time.
>
> In my test on RK3288-Pink2 board, which is not an upstream board yet,
> if external pull-up resistor is 4.7K, rise_ns is about 700ns.
> So the measured high_ns is about 3900ns, which is less than 4000ns
> (the minimum high_ns in I2C specification for Standard-mode).
>
> To fix this bug, min_low_ns should include fall time and min_high_ns
s/,//
> should include rise time too.
I'd skip the "too". If you want to keep it, s/time/time,/.
> This patch merged the patch that Doug submitted to chromium project,
AFAIK s/,//
For correctness, does this patch needs Doug's Sob?
> which can get the rise and fall times for signals from the device tree.
> This allows us to more accurately calculate timings. see:
> https://chromium-review.googlesource.com/#/c/232774/
>
> Signed-off-by: Addy Ke <addy.ke@rock-chips.com>
> ---
> [...]
> @@ -469,29 +476,33 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate, unsigned long scl_rate,
> [...]
> if (scl_rate <= 100000) {
> - min_low_ns = 4700;
> - min_high_ns = 4000;
> - max_data_hold_ns = 3450;
> - data_hold_buffer_ns = 50;
> + /* Standard-mode */
> + spec_min_low_ns = 4700;
> + spec_min_high_ns = 4000;
> + spec_max_data_hold_ns = 3450;
> + spec_data_hold_buffer_ns = 50;
> } else {
> - min_low_ns = 1300;
> - min_high_ns = 600;
> - max_data_hold_ns = 900;
> - data_hold_buffer_ns = 50;
> + /* Fast-mode */
> + spec_min_low_ns = 1300;
> + spec_min_high_ns = 600;
> + spec_max_data_hold_ns = 900;
> + spec_data_hold_buffer_ns = 50;
The background of my question regarding data_hold_buffer_ns in the last
round was: If data_hold_buffer_ns doesn't appear in the I2C
specification, should it be renamed to spec_... ? *shrug*
> }
> - max_low_ns = max_data_hold_ns * 2 - data_hold_buffer_ns;
> + min_low_ns = spec_min_low_ns + fall_ns;
> + min_high_ns = spec_min_high_ns + rise_ns;
> + max_low_ns = spec_max_data_hold_ns * 2 - spec_data_hold_buffer_ns;
> min_total_ns = min_low_ns + min_high_ns;
>
> /* Adjust to avoid overflow */
> @@ -510,8 +521,8 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate, unsigned long scl_rate,
> min_div_for_hold = (min_low_div + min_high_div);
>
> /*
> - * This is the maximum divider so we don't go over the max.
> - * We don't round up here (we round down) since this is a max.
> + * This is the maximum divider so we don't go over the maximum.
> + * We don't round up here (we round down) since this is a maximum.
> */
> max_low_div = clk_rate_khz * max_low_ns / (8 * 1000000);
>
> @@ -544,7 +555,7 @@ static int rk3x_i2c_calc_divs(unsigned long clk_rate, unsigned long scl_rate,
> ideal_low_div = DIV_ROUND_UP(clk_rate_khz * min_low_ns,
> scl_rate_khz * 8 * min_total_ns);
>
> - /* Don't allow it to go over the max */
> + /* Don't allow it to go over the maximum */
> if (ideal_low_div > max_low_div)
> ideal_low_div = max_low_div;
>
> @@ -588,8 +599,8 @@ static void rk3x_i2c_adapt_div(struct rk3x_i2c *i2c, unsigned long clk_rate)
> u64 t_low_ns, t_high_ns;
> int ret;
>
> - ret = rk3x_i2c_calc_divs(clk_rate, i2c->scl_frequency, &div_low,
> - &div_high);
> + ret = rk3x_i2c_calc_divs(clk_rate, i2c->scl_frequency, i2c->rise_ns,
> + i2c->fall_ns, &div_low, &div_high);
>
> WARN_ONCE(ret != 0, "Could not reach SCL freq %u", i2c->scl_frequency);
>
> @@ -633,9 +644,9 @@ static int rk3x_i2c_clk_notifier_cb(struct notifier_block *nb, unsigned long
> switch (event) {
> case PRE_RATE_CHANGE:
> if (rk3x_i2c_calc_divs(ndata->new_rate, i2c->scl_frequency,
> - &div_low, &div_high) != 0) {
> + i2c->rise_ns, i2c->fall_ns, &div_low,
> + &div_high) != 0)
> return NOTIFY_STOP;
> - }
>
> /* scale up */
> if (ndata->new_rate > ndata->old_rate)
> @@ -859,6 +870,21 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
> i2c->scl_frequency = DEFAULT_SCL_RATE;
> }
>
> + /*
> + * Read rise and fall ns.
> + * If not, there use the default maximum from specification.
I'd write:
Read rise and fall time from device tree. If not available use
the default maximum timing from the specification.
(Otherwise I think the comma needs to go after "there" in your
sentence.)
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2014-12-11 7:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 8:11 [PATCH] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C spec Addy Ke
2014-12-02 23:02 ` Doug Anderson
2014-12-03 2:37 ` [PATCH v2] " Addy Ke
2014-12-03 5:13 ` Doug Anderson
2014-12-03 11:15 ` Wolfram Sang
2014-12-03 17:53 ` Doug Anderson
2014-12-04 18:40 ` Wolfram Sang
2014-12-04 18:43 ` Doug Anderson
2014-12-04 19:03 ` Wolfram Sang
2014-12-05 19:31 ` Doug Anderson
2014-12-08 2:59 ` [PATCH v3] " Addy Ke
2014-12-08 3:06 ` addy ke
2014-12-08 8:52 ` Uwe Kleine-König
2014-12-08 17:13 ` Doug Anderson
2014-12-08 17:34 ` Wolfram Sang
2014-12-08 18:53 ` Doug Anderson
2014-12-08 20:04 ` Uwe Kleine-König
2014-12-11 6:00 ` [PATCH v4] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification Addy Ke
2014-12-11 7:47 ` Uwe Kleine-König [this message]
2014-12-11 11:02 ` [PATCH v5] " Addy Ke
2014-12-11 19:22 ` Doug Anderson
2015-01-13 11:42 ` 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=20141211074738.GL13486@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=addy.ke@rock-chips.com \
--cc=caesar.wang@rock-chips.com \
--cc=cf@rock-chips.com \
--cc=dianders@chromium.org \
--cc=galak@codeaurora.org \
--cc=heiko@sntech.de \
--cc=hj@rock-chips.com \
--cc=hl@rock-chips.com \
--cc=huangtao@rock-chips.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kever.yang@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=max.schwarz@online.de \
--cc=olof@lixom.net \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=wsa@the-dreams.de \
--cc=xjq@rock-chips.com \
--cc=yzq@rock-chips.com \
--cc=zhengsq@rock-chips.com \
--cc=zyw@rock-chips.com \
--subject='Re: [PATCH v4] i2c: rk3x: fix bug that cause measured high_ns doesn'\''t meet I2C specification' \
/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
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).