Re: [PATCH V10 1/2] i2c/adapter: Add bus recovery infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux