diff options
| author | Doug Anderson <dianders@chromium.org> | 2014-12-18 18:44:07 +0100 |
|---|---|---|
| committer | Wolfram Sang <wsa@the-dreams.de> | 2015-01-13 16:21:05 +0100 |
| commit | 387f0de6c37380ad72bb92bb621f23555dd4c42e (patch) | |
| tree | 6c93ae93a5c2309c9346607191fa09dc581df286 /Documentation/devicetree | |
| parent | i2c: rk3x: fix bug that cause measured high_ns doesn't meet I2C specification (diff) | |
| download | linux-387f0de6c37380ad72bb92bb621f23555dd4c42e.tar.xz linux-387f0de6c37380ad72bb92bb621f23555dd4c42e.zip | |
i2c: rk3x: Account for repeated start time requirement
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>
[wsa: rebased to i2c/for-next]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Diffstat (limited to 'Documentation/devicetree')
| -rw-r--r-- | Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt index c4fd545720af..f0d71bc52e64 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt @@ -21,14 +21,17 @@ 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 + - i2c-scl-rising-time-ns : Number of nanoseconds the SCL 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 + - i2c-scl-falling-time-ns : Number of nanoseconds the SCL 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. + - i2c-sda-falling-time-ns : Number of nanoseconds the SDA signal takes to fall + (t(f) in the I2C specification). If not specified we'll use the SCL + value since they are the same in nearly all cases. Example: |