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

Commit Message

Felipe Balbi June 7, 2013, 6:39 p.m. UTC

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.

Comments

Tomi Valkeinen June 10, 2013, 9:26 a.m. UTC | #1

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

Patch

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;