Re: i2c issue on Panda with DT boot, v3.10-rc4
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 4807.i2c: timeout waiting for bus ready [5.059417] omap_i2c 4807.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 signature.asc Description: OpenPGP digital signature
Re: i2c issue on Panda with DT boot, v3.10-rc4
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 signature.asc Description: OpenPGP digital signature
Re: i2c issue on Panda with DT boot, v3.10-rc4
* Tomi Valkeinen tomi.valkei...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
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 f0123456789abcdef
00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 80.242980] omap_i2c 4806.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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
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
signature.asc
Description: OpenPGP digital signature
Re: i2c issue on Panda with DT boot, v3.10-rc4
* Tomi Valkeinen tomi.valkei...@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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
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 f0123456789abcdef
00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready
XX [ 80.242980] omap_i2c 4806.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
signature.asc
Description: Digital signature
RE: i2c issue on Panda with DT boot, v3.10-rc4
Tony Lindgren [t...@atomide.com]: * Tomi Valkeinen tomi.valkei...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
* Valkeinen, Tomi tomi.valkei...@ti.com [130607 11:37]: Tony Lindgren [t...@atomide.com]: * Tomi Valkeinen tomi.valkei...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i2c issue on Panda with DT boot, v3.10-rc4
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 f0123456789abcdef 00: 00 [ 72.814086] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 73.825134] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 74.835327] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 76.097167] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 77.160736] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 78.174682] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 79.194824] omap_i2c 4806.i2c: timeout waiting for bus ready XX [ 80.242980] omap_i2c 4806.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 signature.asc Description: Digital signature
