[PATCH v5] i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification
Doug Anderson
dianders at chromium.org
Thu Dec 11 11:22:31 PST 2014
Hi,
On Thu, Dec 11, 2014 at 3:02 AM, Addy Ke <addy.ke at 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 at chromium.org>
Tested-by: Doug Anderson <dianders at chromium.org>
You'll notice that I posted a patch atop it at
<https://patchwork.kernel.org/patch/5477201/>.
-Doug
More information about the linux-arm-kernel
mailing list