Hello everyone,

I am porting OpenWRT (Barrier Breaker) to a RT5350 module. Got it up & running ok and am now trying to enable i2c and i2s to connect an audio codec.

Right now i2c is causing trouble. I am suspecting a hardware error on my board (pad not correctly soldered under the chip or something like that), or... a i2c driver issue.

Has anyone managed to get i2c working ok on RT5350? Known issues, tips?

Thanks
Theo

More details on my setup & experience:

i2c is instantiated correctly:

 
theo@theo-VirtualBox:~/dev$ grep i2c dmesg
[    0.100000] i2c-core: driver [dummy] registered
[    0.190000] rt2880-pinmux pinctrl.2: found group selector 0 for i2c
[    0.190000] rt2880-pinmux pinctrl.2: request pin 1 (io1) for 10000900.i2c
[    0.190000] rt2880-pinmux pinctrl.2: request pin 2 (io2) for 10000900.i2c
[    0.190000] i2c i2c-0: adapter [10000900.i2c] registered
[    0.190000] i2c 0-001a: uevent
[    0.190000] i2c i2c-0: client [wm8731] registered with bus id 0-001a
[    0.190000] i2c-ralink 10000900.i2c: loaded
[    0.690000] i2c /dev entries driver
[    0.700000] i2c-dev: adapter [10000900.i2c] registered as minor 0
[  435.710000] i2c-core: driver [wm8731] registered

There are 1Kohm pull-ups on the bus (from the audio codec board).

But when I try to use it with i2c tools, it does not work ok. I see communication with a BusPirate, but i2cdetect does not work (returns the same address as it tried to detect).

 
root@OpenWrt:~# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 
30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f 
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 
70: 70 71 72 73 74 75 76 77

With the stock i2c-ralink.c driver there is even a condition where the i2c bus gets stuck! Writing twice address without having slave responses makes both sda and sclk to remain low until a reboot. (I am guessing here that the reason for the bus to get stuck is the lack of response from the slave.)

I tried this patch https://raw.githubusercontent.com/sitti … c-ralink.c

i2cdetect now shows some addresses as not responding with the '--' characters, which is what I would expect, but most of them still return the address that was being poked. Interesting to note that the bus does not get stuck anymore as the previous condition, but now every i2cget returns "Error: Read failed".

Anyone who can confirm i2c is working ok on RT5350?

Hello,
I'm currently experimenting with i2c RTC modules and HLK-RM04 board. Everything works fine, except i2cdetect.

Try "-r" switch (i2cdetect -r 0) along with this patch.

I confirm i2cdetect not work , but i2c communication (tested ds1631) work .

My scope confirm that all signals are correct.

(Last edited by silviop on 18 Aug 2014, 21:25)

smarpl, silviop, thanks a lot for your answers.

I still can't i2c to correctly work, but it's good to know it's likely not a driver issue.

My oscilloscope is down, so I can't investigate as much as I'd like in the coming days.

silviop, do you use the stock i2c driver, or the patch from https://raw.githubusercontent.com/sitti … c-ralink.c ?

I compile git downloaded openwrt  with hlk-rm04 default configuration  (add some flyweight  package).

For your knowledge using i2ctool on cubieboard (ARM platform) give a lot of kernel log errors but work too.

Seems that i2c is not ready to be used out of the box .

AFAIK the I2C of the RT305x and RT535x use the same I2C core. I managed to setup the hardware I2C with this code:
https://raw.githubusercontent.com/sitti … c-ralink.c

The dts file looks like:

--- a/target/linux/ramips/dts/CARAMBOLA.dts
+++ b/target/linux/ramips/dts/CARAMBOLA.dts
@@ -10,12 +10,29 @@
                bootargs = "console=ttyS0,115200";
        };
 
+       palmbus@10000000 {
+               i2c@900 {
+                       compatible = "link,rt3052-i2c", "ralink,rt2880-i2c";
+                       reg = <0x900 0x100>;
+
+                       resets = <&rstctrl 16>;
+                       reset-names = "i2c";
+
+                       #address-cells = <1>;
+                       #size-cells = <0>;
+               };
+       };
+
        pinctrl {
                state_default: pinctrl0 {
                        gpio {
-                               ralink,group = "spi", "i2c", "jtag", "rgmii", "mdio", "uartf";
+                               ralink,group = "spi", "jtag", "rgmii", "mdio", "uartf";
                                ralink,function = "gpio";
                        };
+                       i2c {
+                               ralink,group = "i2c";
+                               ralink,function = "i2c";
+                       };
                };
        };
 
@@ -68,10 +85,4 @@
                status = "okay";
        };
 
-       i2c-gpio {
-               compatible = "i2c-gpio";
-
-               gpios = <&gpio0 1 0 &gpio0 2 0>;
-               i2c-gpio,delay-us = <10>;
-       };
 };

Modules are loaded and reading the 24LC256 EEPROM is fine (as long as you ony read <63 bytes in a chunk):

root@Carambola:~# insmod i2c-dev
root@Carambola:~# echo 24c256 0x50 > /sys/bus/i2c/devices/i2c-0/new_device
root@Carambola:~# io 0x10000060 ; dmesg | grep -i i2c ; lsmod | grep -i i2c
10000060:  de

[    0.120000] rt2880-pinmux pinctrl.1: found group selector 0 for i2c
[   10.570000] i2c-ralink 10000900.i2c: loaded
[   65.330000] i2c /dev entries driver
[   68.470000] i2c i2c-0: new_device: Instantiated device 24c256 at 0x50

i2c_core               15054  4 at24
i2c_dev                 4064  0 
i2c_ralink              2432  0 
of_i2c                  1344  1 i2c_ralink

root@Carambola:~# time dd bs=32 count=1024 if=/sys/bus/i2c/devices/0-0050/eeprom | wc -c
1024+0 records in
1024+0 records out
real    0m 1.15s
user    0m 0.01s
sys    0m 1.03s
32768

If I'm going to write to the device with a simple 'echo "u" > /sys/bus/i2c/devices/0-0050/eeprom'
the I2C IP gets stuck. You can see whats happen on the picture:

The first write was successfull (0x50 0x00 0x00 0x75) but the next one fails on the address (0x50 0x00 -> stuck).
The EEPROM need some time to write the first byte but the Ralink I2C sends the next sequence without checking
the slaves ACK (0x50 NAK 0x00 NAK). The clock signal goes low and stay low until the I2C core is being resetted.

In contrast the working bitbanged I2C does following:

root@Carambola:~# echo "u" > /sys/bus/i2c/devices/0-0050/eeprom

[  268.810000] i2c i2c-0: emitting start condition
[  268.810000] i2c i2c-0: i2c_outb: 0xa0 A
[  268.810000] i2c i2c-0: i2c_outb: 0x00 A
[  268.810000] i2c i2c-0: i2c_outb: 0x00 A
[  268.810000] i2c i2c-0: i2c_outb: 0x75 A
[  268.810000] i2c i2c-0: wrote 3 bytes
[  268.810000] i2c i2c-0: emitting stop condition
[  268.810000] i2c i2c-0: emitting start condition
[  268.810000] i2c i2c-0: i2c_outb: 0xa0 NA
[  268.810000] i2c i2c-0: emitting stop condition
[  268.810000] i2c i2c-0: emitting start condition
[  268.810000] i2c i2c-0: i2c_outb: 0xa0 NA
[  268.810000] i2c i2c-0: emitting stop condition
[  268.810000] i2c i2c-0: emitting start condition
[  268.810000] i2c i2c-0: i2c_outb: 0xa0 NA
[  268.810000] i2c i2c-0: emitting stop condition
[  268.810000] i2c i2c-0: emitting start condition
[  268.810000] i2c i2c-0: i2c_outb: 0xa0 NA
[  268.810000] i2c i2c-0: NAK from device addr 0x50 msg #0
[  268.810000] i2c i2c-0: emitting stop condition
<short break>
[  268.830000] i2c i2c-0: emitting start condition
[  268.830000] i2c i2c-0: i2c_outb: 0xa0 A
[  268.830000] i2c i2c-0: i2c_outb: 0x00 A
[  268.830000] i2c i2c-0: i2c_outb: 0x01 A
[  268.830000] i2c i2c-0: i2c_outb: 0x0a A
[  268.830000] i2c i2c-0: wrote 3 bytes
[  268.830000] i2c i2c-0: emitting stop condition

The first sequence is send (0x50 0x00 0x00 0x75) and the next (0x50) is repeated 3 times. There is no ACK from the client. The driver waits some ms and send the second sequence  (0x50 0x00 0x01 0x0A) with success.
The bitbang I2C seems to check every ACK if needed.

I'm not a I2C expert (my first attemp to use/debug the I2C these days) and don't know how other I2C cores behave. IMHO these are the problems with Ralink I2C core / driver:
- the I2C core might hang and the drive should reset it
- some I2C sequences need a short break (might be better integrated in the slave drivers ?)

Any ideas to solve the problems ?

Regards

Gerd

(Last edited by bertc3p0 on 26 Aug 2014, 20:00)

i try patched driver and give better i2cdetect.

here ack code of i2c-ralink.c

it add this function over old version of i2c-ralink:
static inline int rt_i2c_get_ack(void)
{
        return (rt_i2c_r32(REG_STATUS_REG) & I2C_ACKERR) ? -EIO : 0;
}

here the problem:

    if (msg->flags & I2C_M_RD) {
        for (i = 0; i < nblock; i++) {
                    if (rt_i2c_wait_idle()) {
                           printk("i2c-read line busy\n");
                         return -ETIMEDOUT;
                    }
            rt_i2c_w32(READ_BLOCK - 1, REG_BYTECNT_REG);
            rt_i2c_w32(READ_CMD, REG_STARTXFR_REG);
            for (j = 0; j < READ_BLOCK; j++) {
                if ((ret=rt_i2c_wait_rx_done())<0)
                    return ret;
                                if ((ret=rt_i2c_get_ack())<0)
                                        return ret;

                msg->buf[pos++] = rt_i2c_r32(REG_DATAIN_REG);
            }
        }

        if (rt_i2c_wait_idle()) {
            printk("i2c-read line busy\n");
            return -ETIMEDOUT;
        }

        rt_i2c_w32(rem - 1, REG_BYTECNT_REG);
        rt_i2c_w32(READ_CMD, REG_STARTXFR_REG);

what happen here if rem is zero ?

when i2c hang you can issue :
io -4 -w 0x10000034 0x00010000
to reset all i2c subsystem is not very clean but in a script can help!

remember that  stuck eeprom is waiting for clock and it take sda low , so you have to send 9 clock on SCL probably
disabling i2c  (reg 0x10000060 bit 0) and sending it through gpio.

(Last edited by silviop on 26 Sep 2014, 15:19)

https://raw.githubusercontent.com/sitti … c-ralink.c
contains another bug

in implementation :

            if ((ret=rt_i2c_wait_rx_done())<0)
                return ret;
            if ((ret=rt_i2c_get_ack())<0)
                return ret;

should be

             if (rt_i2c_wait_tx_done()<0) ret = rt_i2c_wait_tx_done();
             if (rt_i2c_get_ack()<0)      ret = rt_i2c_get_ack();

because you cannot stop and exit a cycle if you load REG_DATAOUT_REG without
send correct number of bytes (it hang i2c state machine).

(Last edited by silviop on 30 Sep 2014, 13:27)

Hi silviop,

thx for your hints. I will have a look at this ...

Regards

Gerd

I am having similar issues with i2c detect.  I have a MPL3115A2 temperature  and pressure sensor.  http://www.adafruit.com/product/1893
Here are the  results of my dmesg showing i2c registering.

[   17.720000] i2c-dev: adapter [10000900.i2c] registered as minor 0
[   17.720000] i2c i2c-0: adapter [10000900.i2c] registered
[   17.720000] i2c i2c-0: of_i2c: walking child nodes
[   17.720000] i2c-ralink 10000900.i2c: loaded

When I run  i2cdetect -l
i2c-0   i2c             10000900.i2c                            I2C adapter

When  I run i2cdetect 0 I get
      0  1  2  3   4   5   6    7   8  9    a    b    c    d   e   f
00:            03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: -- -- -- -- -- -- -- -- 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: -- -- 52 -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77 

I  am using the patch listed below by bertc3p0
I do not have anything to analyze my digital signals so I cannot confirm whether signals are being sent correctly.
I am using the awm002 asiarf module.

I get this  in my logs after running i2cdetect 0.
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x60, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x61
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x61, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x62
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x62, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x63
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x63, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x64
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x64, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x65
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x65, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x66
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x66, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x67
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x67, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x68
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x68, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x69
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x69, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x6a
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x6a, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x6b
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x6b, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x6c
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x6c, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x6d
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x6d, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x6e
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x6e, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x6f
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x6f, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x70
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x70, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x71
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x71, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x72
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x72, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x73
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x73, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x74
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x74, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x75
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x75, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x76
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x76, len=0
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x703, arg=0x77
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: ioctl, cmd=0x720, arg=0x7f89b5c8
Wed Dec 17 02:59:21 2014 kern.debug kernel: [  743.250000] i2c i2c-0: master_xfer[0] W, addr=0x77, len=0

Any ideas about this one guys.

I found another problem in i2c on rt5350 trying hih6130 i2c  driver.

i2c-ralink declare I2C_FUNC_SMBUS_EMUL that means I2C_FUNC_SMBUS_QUICK  but is not true because in
rt5350 is impossible to send zero bytes (REG_BYTECNT_REG is number of byte to send *plus one*).

Does someone reach my conclusion ?
I remove  I2C_FUNC_SMBUS_QUICK but i2cdetect stop working.