On 21 March 2013 15:06, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > I applied V11 of the core changes with minor modifications. Wow!! Thanks. > I do wonder > about the hook in the designware driver. You apply the recovery on > transfer timeout. I think this should go into the timeout of > i2c_dw_wait_bus_not_busy()? Hmm.. Rajeev/Shiraz were the guys who tested this code earlier and i am sure we were failing in this piece of code, which i just fixed and so i2c_dw_wait_bus_not_busy() didn't fail for us. Below is a conversation that we had with Uwe some time back on the exact problem we faced and it was a bit different from the traditional problem. So, maybe we need bus recovery at both places: i2c_dw_wait_bus_not_busy() (for the traditional hang) and during transfer (for our case). -- viresh > On 7 November 2012 18:53, Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > Hello Viresh, > > > > in our irc conversation you told that the SDA signal being stuck low > > happened with an sta529 audio codec. I quickly scanned over its > > datasheet (Doc ID 13095 Rev 3; March 2012). > > > > Some questions that come to my mind regarding your issue: > > - What is the situation the stall occurs? How do you reproduce? I2C data lines are permanently held low by the slave device (sta529 codec in this case). There is a fixed way in which we can always reproduce it. The codec can support different sample rate. As soon as we switch from one sample rate to another (and accordingly re-configure sta529), this happens. > > - I didn't find a specification of the allowed i2c clock frequency. Do > > you have a different document that specifies this? (Or maybe I just > > missed it?!) I assume you're using the device in the right range? sta529 can work in fast mode at 400 KHz without any issues. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
