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

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

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Grygorii Strashko]

hi Tomi,
On 06/07/2013 02:53 PM, Tomi Valkeinen wrote:
> 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
>
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
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -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

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

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On 07/06/13 15:36, Grygorii Strashko wrote:

> 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
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -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;

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@ti.com> [130607 05:53]:
> On 07/06/13 15:36, Grygorii Strashko wrote:
> 
> > 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
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -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;
> 
> 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.

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

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

[Valkeinen, Tomi]

Tony Lindgren [tony@atomide.com]:

> * Tomi Valkeinen <tomi.valkeinen@ti.com> [130607 05:53]:

> > 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

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

[Tony Lindgren]

* Valkeinen, Tomi <tomi.valkeinen@ti.com> [130607 11:37]:
> Tony Lindgren [tony@atomide.com]:
> 
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [130607 05:53]:
> 
> > > 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.

OK, that's probably I had it working.
 
> 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

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

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On 07/06/13 21:36, Tony Lindgren wrote:

> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

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

[Tony Lindgren]

* Tomi Valkeinen <tomi.valkeinen@iki.fi> [130610 02:35]:
> On 07/06/13 21:36, Tony Lindgren wrote:
> 
> > 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

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

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

HI,

On Fri, Jun 07, 2013 at 03:36:38PM +0300, Grygorii Strashko wrote:
> hi Tomi,
> On 06/07/2013 02:53 PM, Tomi Valkeinen wrote:
> >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
> >
> 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
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -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);
> +

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

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

Hi,

On Fri, Jun 07, 2013 at 02:53:54PM +0300, Tomi Valkeinen wrote:
> 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...

> 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?

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.

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index aa3b91e..471b434 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -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;

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On 07/06/13 21:39, Felipe Balbi wrote:

> 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.
> 
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index aa3b91e..471b434 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]