| Message ID | 1447338715-9955-6-git-send-email-wsa@the-dreams.de |
|---|---|
| State | Superseded |
| Headers | show |
Hi Wolfram, Thank you for the patch. Sorry for bringing bad news, but as with v1, this patch breaks ADV7511 detection on my Koelsch board. Reverting it on top of the series fixes the problem. You'll find the dmesg and trace logs with your debugging patch applied attached to this e-mail in two versions, one with the whole series applied (- bad) and one with this patch additionally reverted on top of the series (- good). On Thursday 12 November 2015 15:31:50 Wolfram Sang wrote: > From: Wolfram Sang <wsa+renesas@sang-engineering.com> > > We want to reuse this function later. > > Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> > --- > drivers/i2c/busses/i2c-rcar.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c > index 0f2dc74ab8bcc1..4bd3099865b485 100644 > --- a/drivers/i2c/busses/i2c-rcar.c > +++ b/drivers/i2c/busses/i2c-rcar.c > @@ -106,7 +106,8 @@ enum rcar_i2c_type { > struct rcar_i2c_priv { > void __iomem *io; > struct i2c_adapter adap; > - struct i2c_msg *msg; > + struct i2c_msg *msg; > + int msgs_left; > struct clk *clk; > > wait_queue_head_t wait; > @@ -255,6 +256,11 @@ static void rcar_i2c_prepare_msg(struct rcar_i2c_priv > *priv) { > int read = !!rcar_i2c_is_recv(priv); > > + priv->pos = 0; > + priv->flags = 0; > + if (priv->msgs_left == 1) > + rcar_i2c_flags_set(priv, ID_LAST_MSG); > + > rcar_i2c_write(priv, ICMAR, (priv->msg->addr << 1) | read); > rcar_i2c_write(priv, ICMSR, 0); > rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_START); > @@ -499,11 +505,8 @@ static int rcar_i2c_master_xfer(struct i2c_adapter > *adap, } > > /* init each data */ > - priv->msg = &msgs[i]; > - priv->pos = 0; > - priv->flags = 0; > - if (i == num - 1) > - rcar_i2c_flags_set(priv, ID_LAST_MSG); > + priv->msg = &msgs[i]; > + priv->msgs_left = num - i; > > rcar_i2c_prepare_msg(priv);
Hi Laurent, > Sorry for bringing bad news, but as with v1, this patch breaks ADV7511 > detection on my Koelsch board. Reverting it on top of the series fixes the > problem. In v1, patch 5/9 was breaking. I hope in v2, it is 6/10 and not 5/10 as you replied to (patch 1/10 is the new one)? This bug is strange enough, but 5/10 breaking would be extremly crazy. > You'll find the dmesg and trace logs with your debugging patch applied > attached to this e-mail in two versions, one with the whole series applied (- > bad) and one with this patch additionally reverted on top of the series (- > good). Thanks for doing this. I'll think about it some more, but it may be that I am running out of ideas without being able to connect a scope. Would it be possible to exchange our Koelsch and Lager boards for a while? Or is your multimedia work Koelsch dependant? Thanks, Wolfram
Hi Wolfram, On Tuesday 17 November 2015 08:00:53 Wolfram Sang wrote: > Hi Laurent, > > > Sorry for bringing bad news, but as with v1, this patch breaks ADV7511 > > detection on my Koelsch board. Reverting it on top of the series fixes the > > problem. > > In v1, patch 5/9 was breaking. I hope in v2, it is 6/10 and not 5/10 as > you replied to (patch 1/10 is the new one)? This bug is strange enough, > but 5/10 breaking would be extremly crazy. My bad, it's indeed "[PATCH v2 06/10] i2c: rcar: init new messages in irq" that I have reverted on top of the series. > > You'll find the dmesg and trace logs with your debugging patch applied > > attached to this e-mail in two versions, one with the whole series applied > > (- bad) and one with this patch additionally reverted on top of the > > series (- good). > > Thanks for doing this. I'll think about it some more, but it may be that > I am running out of ideas without being able to connect a scope. Would > it be possible to exchange our Koelsch and Lager boards for a while? Or > is your multimedia work Koelsch dependant? I'm currently doing multimedia development on Koelsch. I'll check whether I can continue that on Lager. In the meantime I could also capture I2C traces using a scope and send them to you.
Hi Wolfram, On Tue, Nov 17, 2015 at 4:00 PM, Wolfram Sang <wsa@the-dreams.de> wrote: > Hi Laurent, > >> Sorry for bringing bad news, but as with v1, this patch breaks ADV7511 >> detection on my Koelsch board. Reverting it on top of the series fixes the >> problem. > > In v1, patch 5/9 was breaking. I hope in v2, it is 6/10 and not 5/10 as > you replied to (patch 1/10 is the new one)? This bug is strange enough, > but 5/10 breaking would be extremly crazy. > >> You'll find the dmesg and trace logs with your debugging patch applied >> attached to this e-mail in two versions, one with the whole series applied (- >> bad) and one with this patch additionally reverted on top of the series (- >> good). > > Thanks for doing this. I'll think about it some more, but it may be that > I am running out of ideas without being able to connect a scope. Would > it be possible to exchange our Koelsch and Lager boards for a while? Or > is your multimedia work Koelsch dependant? Swapping boards is of course one option, but shouldn't it also be possible to reproduce the issue by creating a similar hardware setup using loopback adapters? The problem is that you cannot reproduce it on your current hardware, right? Judging by the Koelsch schematics port EXIO_C has GP6_22/GP6_23 routed as SD2_CD_3/SC2_WP_3 that may be possible to repurpose as IIC1_SCL_C/IIC1_SDA_C. So if you want to try an IIC master device on Koeslch with the I2C2 devices that hold the ADV7511 chip then you should be able to use those ZEBAX adapters and loopback wires. If you want to sniff the I2C2 signals on Koelsch then the I2C2 bus is exposed to EXIO_A and EXIO_D. On Lager it seems that the GP5_5/GP_6 pins with the I2C2 bus for the ADV7511 chip has more flexible configuration, so using either IIC or I2C should be possible. You can sample those pins on EXIO_A with the ZEBAX break out adapter. And either way you should be able to compare the results of the I2C and IIC masters with GPIO using the bitbang implementation. Feel free to let me know exactly what the problem is and I will do my best to help you out! Thanks, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Magnus, On Wednesday 18 November 2015 11:18:00 Magnus Damm wrote: > On Tue, Nov 17, 2015 at 4:00 PM, Wolfram Sang <wsa@the-dreams.de> wrote: > > Hi Laurent, > > > >> Sorry for bringing bad news, but as with v1, this patch breaks ADV7511 > >> detection on my Koelsch board. Reverting it on top of the series fixes > >> the problem. > > > > In v1, patch 5/9 was breaking. I hope in v2, it is 6/10 and not 5/10 as > > you replied to (patch 1/10 is the new one)? This bug is strange enough, > > but 5/10 breaking would be extremly crazy. > > > >> You'll find the dmesg and trace logs with your debugging patch applied > >> attached to this e-mail in two versions, one with the whole series > >> applied (- bad) and one with this patch additionally reverted on top of > >> the series (- good). > > > > Thanks for doing this. I'll think about it some more, but it may be that > > I am running out of ideas without being able to connect a scope. Would > > it be possible to exchange our Koelsch and Lager boards for a while? Or > > is your multimedia work Koelsch dependant? > > Swapping boards is of course one option, but shouldn't it also be > possible to reproduce the issue by creating a similar hardware setup > using loopback adapters? The problem is that you cannot reproduce it > on your current hardware, right? If I remember correctly not only has Wolfram not been able to reproduce the problem on his Lager board, but he hasn't been able to reproduce it you the remote access Koelsch board. I'm not sure how he could try to reproduce it locally with a "similar hardware setup" on Lager if it can't be reproduced on a different Koelsch board :-) > Judging by the Koelsch schematics port EXIO_C has GP6_22/GP6_23 routed > as SD2_CD_3/SC2_WP_3 that may be possible to repurpose as > IIC1_SCL_C/IIC1_SDA_C. So if you want to try an IIC master device on > Koeslch with the I2C2 devices that hold the ADV7511 chip then you > should be able to use those ZEBAX adapters and loopback wires. If you > want to sniff the I2C2 signals on Koelsch then the I2C2 bus is exposed > to EXIO_A and EXIO_D. > > On Lager it seems that the GP5_5/GP_6 pins with the I2C2 bus for the > ADV7511 chip has more flexible configuration, so using either IIC or > I2C should be possible. You can sample those pins on EXIO_A with the > ZEBAX break out adapter. > > And either way you should be able to compare the results of the I2C > and IIC masters with GPIO using the bitbang implementation. > > Feel free to let me know exactly what the problem is and I will do my > best to help you out!
> can continue that on Lager. In the meantime I could also capture I2C traces > using a scope and send them to you. Cool, thanks! I think I'll start with sending you another trace-printk patch soon. And can you push the branch you were using somewhere? With the config as an additional commit?
> On Lager it seems that the GP5_5/GP_6 pins with the I2C2 bus for the > ADV7511 chip has more flexible configuration, so using either IIC or > I2C should be possible. You can sample those pins on EXIO_A with the > ZEBAX break out adapter. Yes, that's what I basically did here for developing the whole patch series and for the recent testing. A simple 's/iic2/i2c2/g' on the Lager DTS does the trick.
Hi Wolfram, On Wed, Nov 18, 2015 at 5:07 PM, Wolfram Sang <wsa@the-dreams.de> wrote: > >> On Lager it seems that the GP5_5/GP_6 pins with the I2C2 bus for the >> ADV7511 chip has more flexible configuration, so using either IIC or >> I2C should be possible. You can sample those pins on EXIO_A with the >> ZEBAX break out adapter. > > Yes, that's what I basically did here for developing the whole patch > series and for the recent testing. A simple 's/iic2/i2c2/g' on the Lager > DTS does the trick. Great, thanks! Lager seems to work well, but I wonder why Koelsch is unstable... / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c index 0f2dc74ab8bcc1..4bd3099865b485 100644 --- a/drivers/i2c/busses/i2c-rcar.c +++ b/drivers/i2c/busses/i2c-rcar.c @@ -106,7 +106,8 @@ enum rcar_i2c_type { struct rcar_i2c_priv { void __iomem *io; struct i2c_adapter adap; - struct i2c_msg *msg; + struct i2c_msg *msg; + int msgs_left; struct clk *clk; wait_queue_head_t wait; @@ -255,6 +256,11 @@ static void rcar_i2c_prepare_msg(struct rcar_i2c_priv *priv) { int read = !!rcar_i2c_is_recv(priv); + priv->pos = 0; + priv->flags = 0; + if (priv->msgs_left == 1) + rcar_i2c_flags_set(priv, ID_LAST_MSG); + rcar_i2c_write(priv, ICMAR, (priv->msg->addr << 1) | read); rcar_i2c_write(priv, ICMSR, 0); rcar_i2c_write(priv, ICMCR, RCAR_BUS_PHASE_START); @@ -499,11 +505,8 @@ static int rcar_i2c_master_xfer(struct i2c_adapter *adap, } /* init each data */ - priv->msg = &msgs[i]; - priv->pos = 0; - priv->flags = 0; - if (i == num - 1) - rcar_i2c_flags_set(priv, ID_LAST_MSG); + priv->msg = &msgs[i]; + priv->msgs_left = num - i; rcar_i2c_prepare_msg(priv);