Switch to the new generic functions: i2c_parse_fw_timings().
Signed-off-by: NDavid Wu <david.wu@rock-chips.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Enable the I2C core for this SoC.
Signed-off-by: NYakir Yang <ykk@rock-chips.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Cc: stable@kernel.org

This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Although unlikely, it is remotely possible for an i2c command to need
more than 200ms complete. Unlike smbus, i2c devices can clock stretch
for an unspecified amount of time. The longest time I've seen
specified for a device is 144ms (bq27541 battery gas), but one could
imagine a device taking a bit slower. 1 second "ought to be enough for
anyone."

The above is not the only justifcation for going above 200ms for a
timeout, though.  It turns out that if you've got a large number of
printks going out to a serial console, interrupts on a CPU can be
disabled for hundreds of milliseconds. That's not a great situation to
be in to start with (maybe we should put a cap in vprintk_emit()) but
it's pretty annoying to start seeing unexplained i2c timeouts.

Note that to understand why we can timeout when printk has interrupts
disabled, you need to understand that on current Linux ARM kernels
interrupts are routed to a single CPU in a multicore system. Thus,
you can get:

1. CPU1 is running rk3x_i2c_xfer()
2. CPU0 calls vprintk_emit(), which disables all IRQs on CPU0.
3. I2C interrupt is ready but is set to only run on CPU0, where IRQs
   are disabled.
4. CPU1 timeout expires. I2C interrupt is still ready, but CPU0 is
   still sitting in the same vprintk_emit()
5. CPU1 sees that no interrupt happened in 200ms, so timeout.

A normal system shouldn't see i2c timeouts anyway, so increasing the
timeout should help people debugging without hurting other people
excessively.
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NCaesar Wang <wxt@rock-chips.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

master_xfer() method should return number of i2c messages transferred,
but on Rockchip we were usually returning just 1, which caused trouble
with users that actually check number of transferred messages vs.
checking for negative error codes.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

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: NDoug Anderson <dianders@chromium.org>
[wsa: rebased to i2c/for-next]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

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: NAddy Ke <addy.ke@rock-chips.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
[wsa: fixed a typo in the docs]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The i2c input clock can change dynamically, e.g. on the RK3066 where
pclk_i2c0 and pclk_i2c1 are connected to the armclk, which changes
rate on cpu frequency scaling.

Until now, we incorrectly called clk_get_rate() while holding the
i2c->lock in rk3x_i2c_xfer() to adapt to clock rate changes.
Thanks to Huang Tao for reporting this issue.

Do it properly now using the clk notifier framework. The callback
logic was taken from i2c-cadence.c.

Also rename all misleading "i2c_rate" variables to "clk_rate", as they
describe the *input* clk rate.
Signed-off-by: NMax Schwarz <max.schwarz@online.de>
Tested-by: Doug Anderson <dianders@chromium.org> on RK3288
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As show in I2C specification:
- Standard-mode: the minimum HIGH period of the scl clock is 4.0us
                 the minimum LOW period of the scl clock is 4.7us
- Fast-mode: the minimum HIGH period of the scl clock is 0.6us
             the minimum LOW period of the scl clock is 1.3us

I have measured i2c SCL waveforms in fast-mode by oscilloscope
on rk3288-pinky board. the LOW period of the scl clock is 1.3us.
It is so critical that we must adjust LOW division to increase
the LOW period of the scl clock.

Thanks Doug for the suggestion about division formulas.
Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

i2cdetect -q was broken (everything was a false positive, and no transfers were
actually being sent over i2c). The way it works is by sending a 0 length write
request and checking for NACK. This patch fixes the 0 length writes and actually
sends them.
Reported-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

Having a transfer more than 32 bits is not all that unlikely.  Remove
the annotation.

The unlikely in the IRQ handler can't gain us much.  It's not in a
loop, so at most it would save 1 instruction per IRQ, which isn't
much.  In fact on the compiler I tested it produced the exact same
code.  Remove it too.
Suggested-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I2C_CLKDIV register descripted in the previous version of
RK3x chip manual is incorrect. Plus 1 is required.

The correct formula:
- T(SCL_HIGH) = T(PCLK) * (CLKDIVH + 1) * 8
- T(SCL_LOW) = T(PCLK) * (CLKDIVL + 1) * 8
- (SCL Divsor) = 8 * ((CLKDIVL + 1) + (CLKDIVH + 1))
- SCL = PCLK / (CLK Divsor)

It will be updated to the latest version of chip manual.
Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data
in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx
must be less than or equal 32 bytes at a time.

Tested on rk3288-pinky board, elan receive 158 bytes data.
Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
Acked-by: NMax Schwarz <max.schwarz@online.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

If slave holds scl, I2C_IPD[7] will be set 1 by controller
for debugging. Driver must ignore it.

[    5.752391] rk3x-i2c ff160000.i2c: unexpected irq in WRITE: 0x80
[    5.939027] rk3x-i2c ff160000.i2c: timeout, ipd: 0x80, state: 4
Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

drivers/i2c/busses/i2c-rk3x.c:610:69-70: rk3x_i2c_match is not NULL terminated at line 610

Make sure of_device_id tables are NULL terminated
Generated by: /kbuild/src/linux/scripts/coccinelle/misc/of_table.cocci
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.

Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>