i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification

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
should include rise time.

This patch merged the patch from chromium project 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>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
[wsa: fixed a typo in the docs]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

1 files changed, 11 insertions, 0 deletions

diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
index dde6c22ce91a..c4fd545720af 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt
@@ -21,6 +21,14 @@ Required on RK3066, RK3188 :
 Optional properties :
 
  - 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 slower communication.
 
 Example:
 
@@ -39,4 +47,7 @@ i2c0: i2c@2002d000 {
 
         clock-names = "i2c";
         clocks = <&cru PCLK_I2C0>;
+
+        i2c-scl-rising-time-ns = <800>;
+        i2c-scl-falling-time-ns = <100>;
 };