Skip to contentSkip to conversation

i2c issue on Panda with DT boot, v3.10-rc4

DISCUSSION Tomi Valkeinen 5 participants 11 messages Jun 7, 2013 – Jun 10, 2013

Subsystems (4)
I2C subsystem host drivers OMAP2+ support OMAP1 support OMAP I2C driver
lore
Share & tools
lore

Tomi Valkeinen

author
#0 lore raw

Hi,

I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the DVI output's EDID reading to work. Testing with i2cget and i2cdump, I see that I can read individual bytes with i2cget, but using i2cdump doesn't work, it just shows 'XX'es.

The same issue is there with 3.10-rc4, although with that one I get timeouts with i2cdump, whereas there were no timeouts with -rc1.

# i2cget -y 2 0x50 0x10
0x0a
# i2cget -y 2 0x50 0x20
0x0f
# i2cget -y 2 0x50 0x30
0x01
# i2cget -y 2 0x50 0x40
0x36
# i2cget -y 2 0x50 0x50
0x4c
# i2cdump -y 2 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 [   72.814086] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   73.825134] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   74.835327] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   76.097167] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   77.160736] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   78.174682] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   79.194824] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   80.242980] omap_i2c 48060000.i2c: timeout waiting for bus ready

i2cdump works fine with non-DT boot (but the i2c bus number is 3).

Any ideas?

Tomi

#1 lore raw

hi Tomi,

Quoted 32 lines · Tomi Valkeinen

Hi,

I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the DVI output's EDID reading to work. Testing with i2cget and i2cdump, I see that I can read individual bytes with i2cget, but using i2cdump doesn't work, it just shows 'XX'es.

The same issue is there with 3.10-rc4, although with that one I get timeouts with i2cdump, whereas there were no timeouts with -rc1.

# i2cget -y 2 0x50 0x10
0x0a
# i2cget -y 2 0x50 0x20
0x0f
# i2cget -y 2 0x50 0x30
0x01
# i2cget -y 2 0x50 0x40
0x36
# i2cget -y 2 0x50 0x50
0x4c
# i2cdump -y 2 0x50
No size specified (using byte-data access)
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 [   72.814086] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   73.825134] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   74.835327] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   76.097167] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   77.160736] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   78.174682] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   79.194824] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   80.242980] omap_i2c 48060000.i2c: timeout waiting for bus ready
Quoted 6 lines

i2cdump works fine with non-DT boot (but the i2c bus number is 3).

Any ideas?

Tomi

Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 13d1eca..66a62e7 100644

drivers/i2c/busses/i2c-omap.c +5 -5
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
        if (dev->cmd_err & OMAP_I2C_STAT_NACK) {
                if (msg->flags & I2C_M_IGNORE_NAK)
                        return 0;
-               if (stop) {
-                       w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
-                       w |= OMAP_I2C_CON_STP;
-                       omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
-               }
+
+               w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+               w |= OMAP_I2C_CON_STP;
+               omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
                return -EREMOTEIO;
        }
        return -EIO;

-grygorii

author
#2 lore raw
Quoted 22 lines · Grygorii Strashko

Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 13d1eca..66a62e7 100644

drivers/i2c/busses/i2c-omap.c +5 -5
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
 *adap,
        if (dev->cmd_err & OMAP_I2C_STAT_NACK) {
                if (msg->flags & I2C_M_IGNORE_NAK)
                        return 0;
-               if (stop) {
-                       w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
-                       w |= OMAP_I2C_CON_STP;
-                       omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
-               }
+
+               w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+               w |= OMAP_I2C_CON_STP;
+               omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
                return -EREMOTEIO;
        }
Quoted 1 line
        return -EIO;

With that one, I don't get timeouts, but it still doesn't work (i.e. behavior is the same as on -rc1).

When I run i2cdump the first time, I see that it (probably) manages to read the first byte, as that's "00". Everything after that are 'XX'es.

Tomi

maintainer
#3 lore raw
Quoted 29 lines · Tomi Valkeinen
Quoted 22 lines · Grygorii Strashko

Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 13d1eca..66a62e7 100644

drivers/i2c/busses/i2c-omap.c +5 -5
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
 *adap,
        if (dev->cmd_err & OMAP_I2C_STAT_NACK) {
                if (msg->flags & I2C_M_IGNORE_NAK)
                        return 0;
-               if (stop) {
-                       w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
-                       w |= OMAP_I2C_CON_STP;
-                       omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
-               }
+
+               w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+               w |= OMAP_I2C_CON_STP;
+               omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+
                return -EREMOTEIO;
        }
Quoted 1 line
        return -EIO;

With that one, I don't get timeouts, but it still doesn't work (i.e. behavior is the same as on -rc1).

Quoted 2 lines

When I run i2cdump the first time, I see that it (probably) manages to read the first byte, as that's "00". Everything after that are 'XX'es.

Hmm I suggest git bisect, I'm pretty sure I was using my panda es with my omap4 DT conversion patches against v3.10-rc1.

In any case, please also test your changes against the current omap-for-v3.11/cleanup branch that drops omap4 legacy hwmod data for the parts that should come from DT. If you see some additional issues with that, we can revert the related parts of the last patch in omap-for-v3.11/cleanup.

Regards,

Tony

author
#4 lore raw

Tony Lindgren [[email protected]]:

Quoted 10 lines · Tomi Valkeinen
Quoted 6 lines

With that one, I don't get timeouts, but it still doesn't work (i.e. behavior is the same as on -rc1).

When I run i2cdump the first time, I see that it (probably) manages to read the first byte, as that's "00". Everything after that are 'XX'es.

Hmm I suggest git bisect, I'm pretty sure I was using my panda es with my omap4 DT conversion patches against v3.10-rc1.

As I mentioned, it doesn't work on v3.10-rc1 either. Note that DVI output itself works fine, it's the EDID read that fails. So if you force the videomode, you won't notice anything.

I didn't try with v3.9 (does DT boot work on that one?), though. So I don't know if reading EDID has ever worked with DT boot.

Tomi

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

maintainer
#5 lore raw
Quoted 10 lines · Valkeinen, Tomi

Tony Lindgren [[email protected]]:

Quoted 8 lines · Tomi Valkeinen
Quoted 6 lines

With that one, I don't get timeouts, but it still doesn't work (i.e. behavior is the same as on -rc1).

When I run i2cdump the first time, I see that it (probably) manages to read the first byte, as that's "00". Everything after that are 'XX'es.

Quoted 6 lines
Quoted 2 lines

Hmm I suggest git bisect, I'm pretty sure I was using my panda es with my omap4 DT conversion patches against v3.10-rc1.

As I mentioned, it doesn't work on v3.10-rc1 either. Note that DVI output itself works fine, it's the EDID read that fails. So if you force the videomode, you won't notice anything.

OK, that's probably I had it working.

Quoted 2 lines

I didn't try with v3.9 (does DT boot work on that one?), though. So I don't know if reading EDID has ever worked with DT boot.

Yes but requires several fixes. Without fixes, v3.10-rc4 is your best bet. Of course that won't help much with git bisect.

Maybe check that the i2c related pins are muxed properly for your board with pinctrl-single?

Regards,

Tony

#6 lore raw
Quoted 2 lines · Tony Lindgren

Maybe check that the i2c related pins are muxed properly for your board with pinctrl-single?

Reading the bytes individually with i2cget works fine, so I think that tells us that the pins are configured ok.

Tomi

maintainer
#7 lore raw
Quoted 7 lines · Tomi Valkeinen
Quoted 2 lines · Tony Lindgren

Maybe check that the i2c related pins are muxed properly for your board with pinctrl-single?

Reading the bytes individually with i2cget works fine, so I think that tells us that the pins are configured ok.

Yes OK. Maybe there's some i2c driver errata that's not getting configured with the DT based boot?

Regards,

Tony

#8 lore raw
In reply to Grygorii Strashko

HI,

Quoted 49 lines · Grygorii Strashko

hi Tomi,

Quoted 32 lines · Tomi Valkeinen

Hi,

I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the DVI output's EDID reading to work. Testing with i2cget and i2cdump, I see that I can read individual bytes with i2cget, but using i2cdump doesn't work, it just shows 'XX'es.

The same issue is there with 3.10-rc4, although with that one I get timeouts with i2cdump, whereas there were no timeouts with -rc1.

# i2cget -y 2 0x50 0x10
0x0a
# i2cget -y 2 0x50 0x20
0x0f
# i2cget -y 2 0x50 0x30
0x01
# i2cget -y 2 0x50 0x40
0x36
# i2cget -y 2 0x50 0x50
0x4c
# i2cdump -y 2 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 [   72.814086] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   73.825134] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   74.835327] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   76.097167] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   77.160736] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   78.174682] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   79.194824] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   80.242980] omap_i2c 48060000.i2c: timeout waiting for bus ready
Quoted 6 lines

i2cdump works fine with non-DT boot (but the i2c bus number is 3).

Any ideas?

Tomi

Could you check if below change will help you, pls?
iff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 13d1eca..66a62e7 100644

drivers/i2c/busses/i2c-omap.c +0 -0
@@ -615,11 +615,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
        if (dev->cmd_err & OMAP_I2C_STAT_NACK) {
                if (msg->flags & I2C_M_IGNORE_NAK)
                        return 0;

drivers/i2c/busses/i2c-omap.c static int omap_i2c_xfer_msg(struct i2c_adapter *adap, · line 622

Quoted 10 lines
drivers/i2c/busses/i2c-omap.c +5 -5
-               if (stop) {
-                       w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
-                       w |= OMAP_I2C_CON_STP;
-                       omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
-               }
+
+               w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
+               w |= OMAP_I2C_CON_STP;
+               omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
+

don't do this, it will break repeated start.

Signature · 1 line
balbi
#9 lore raw
In reply to Tomi Valkeinen

Hi,

Quoted 6 lines · Tomi Valkeinen

Hi,

I was testing DT boot with 3.10-rc1 and Pandaboard, and couldn't get the DVI output's EDID reading to work. Testing with i2cget and i2cdump, I see that I can read individual bytes with i2cget, but using i2cdump doesn't work, it just shows 'XX'es.

does it work with v3.9 ? The funny thing is that nothing has changed on i2c-omap.c for quite some time...

Quoted 25 lines

The same issue is there with 3.10-rc4, although with that one I get timeouts with i2cdump, whereas there were no timeouts with -rc1.

# i2cget -y 2 0x50 0x10
0x0a
# i2cget -y 2 0x50 0x20
0x0f
# i2cget -y 2 0x50 0x30
0x01
# i2cget -y 2 0x50 0x40
0x36
# i2cget -y 2 0x50 0x50
0x4c
# i2cdump -y 2 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 [   72.814086] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   73.825134] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   74.835327] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   76.097167] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   77.160736] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   78.174682] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   79.194824] omap_i2c 48060000.i2c: timeout waiting for bus ready
XX [   80.242980] omap_i2c 48060000.i2c: timeout waiting for bus ready
Quoted 3 lines

i2cdump works fine with non-DT boot (but the i2c bus number is 3).

Any ideas?

sounds like there's something left in FIFO which is not getting read out, then we end up timing out.

Can you try the patch below ? It's patch of a bigger patchset which I still need to clean a few things up, but they should be very close to being ready. IIRC, one of the patches creates a problem for N900 (only) which gets fixed later, I just need to combine those two patches into one to avoid the regression.

drivers/i2c/busses/i2c-omap.c +1 -2
index aa3b91e..471b434 100644
@@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
 		}
 	} while (stat);
 
-	omap_i2c_complete_cmd(dev, err);
-
 out:
+	omap_i2c_complete_cmd(dev, err);
 	spin_unlock_irqrestore(&dev->lock, flags);
 
 	return IRQ_HANDLED;
Signature · 1 line
balbi
#10 lore raw
Quoted 15 lines · Felipe Balbi

sounds like there's something left in FIFO which is not getting read out, then we end up timing out.

Can you try the patch below ? It's patch of a bigger patchset which I still need to clean a few things up, but they should be very close to being ready. IIRC, one of the patches creates a problem for N900 (only) which gets fixed later, I just need to combine those two patches into one to avoid the regression.

drivers/i2c/busses/i2c-omap.c +0 -0
index aa3b91e..471b434 100644

drivers/i2c/busses/i2c-omap.c omap_i2c_isr_thread(int this_irq, void *dev_id) · line 1029

Quoted 10 lines
drivers/i2c/busses/i2c-omap.c +1 -2
@@ -1022,9 +1022,8 @@ omap_i2c_isr_thread(int this_irq, void *dev_id)
 		}
 	} while (stat);
 
-	omap_i2c_complete_cmd(dev, err);
-
 out:
+	omap_i2c_complete_cmd(dev, err);
 	spin_unlock_irqrestore(&dev->lock, flags);
 
 	return IRQ_HANDLED;

With this change the boot becomes unreliable:

[    3.024322] V2V1: 2100 mV
[    4.049530] omap_i2c 48070000.i2c: timeout waiting for bus ready
[    5.059417] omap_i2c 48070000.i2c: timeout waiting for bus ready
[    5.059448] twl: Write failed (mod 9, reg 0xe5 count 1)

and this continues.

I did manage to boot once, and running i2cdump printed each byte very slowly, and with 0xff as the data.

Tomi