Re: [PATCH v5] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification

From: Doug Anderson <dianders@chromium.org>
To: Addy Ke <addy.ke@rock-chips.com>
Cc: "Wolfram Sang" <wsa@the-dreams.de>,
	"Max Schwarz" <max.schwarz@online.de>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Olof Johansson" <olof@lixom.net>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Pawel Moll" <pawel.moll@arm.com>,
	"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
	"Kumar Gala" <galak@codeaurora.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Eddie Cai" <cf@rock-chips.com>,
	"Jianqun Xu" <xjq@rock-chips.com>,
	"Tao Huang" <huangtao@rock-chips.com>, Chris <zyw@rock-chips.com>,
	姚智情 <yzq@rock-chips.com>, "Han Jiang" <hj@rock-chips.com>,
	"Kever Yang" <kever.yang@rock-chips.com>,
	"Lin Huang" <hl@rock-chips.com>,
	caesar <caesar.wang@rock-chips.com>,
	"Shunqian Zheng" <zhengsq@rock-chips.com>
Subject: Re: [PATCH v5] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification
Date: Thu, 11 Dec 2014 11:22:31 -0800	[thread overview]
Message-ID: <CAD=FV=UCQMRLx2KHzT28iY6uCHGQ0MouWKEeVyv2AF_qNCrT=Q@mail.gmail.com> (raw)
In-Reply-To: <1418295760-19639-1-git-send-email-addy.ke@rock-chips.com>

Hi,

On Thu, Dec 11, 2014 at 3:02 AM, Addy Ke <addy.ke@rock-chips.com> wrote:
>   - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used.
> + - i2c-scl-rising-time-ns : Number of nanoseconds the signal takes to rise
> +       (t(r) in I2C specification). If not specified this is assumed to be
> +       the maximum the specification allows(1000 ns for Standard-mode,
> +       300 ns for Fast-mode) which might cause slightly slower communication.
> + - i2c-scl-falling-time-ns : Number of nanoseconds the signal takes to fall
> +       (t(f) in the I2C specification). If not specified this is assumed to
> +       be the maximum the specification allows (300 ns) which might cause
> +       slightly slowercommunication.

nit: you forgot a space between "slower" and "communication".

...this is the type of thing I think Wolfram can fixup when applying,
so I'd suggest against respinning unless something else is needed.

Overall I continue to be happy with this patch.

Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>

You'll notice that I posted a patch atop it at
<https://patchwork.kernel.org/patch/5477201/>.

-Doug