On Thu, Jan 30, 2014 at 7:30 AM, Ivan T. Ivanov [off-list ref] wrote:

Hi Bjorn,

On Wed, 2014-01-29 at 08:32 -0800, Bjorn Andersson wrote:

quoted

On Wed, Jan 29, 2014 at 12:14 AM, Ivan T. Ivanov [off-list ref] wrote:

quoted

Hi Bjorn,

On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:

quoted

Continuing on Ivans i2c-qup series.

Do you plan to send v4 of this driver? I would like to address
the remaining errors and suggestions and send a new version.

Hi Ivan,

Yes I'm planning to send out a new revision of the patch set.

I've incorporated fixes from the review comments here and my colleague
concluded through some testing that block read did not work, so we've
fixed that as well.

Busted. I have not test it.

No worries, I'm glad you did the major cleanup from codeaurora!

quoted

What have been holding me from submitting a new patchset is the 3
functions that does polling of state and status updates;
* qup_i2c_poll_state() reads the state register up to 1000 times,
hoping we reach the expected state, will delay 100uS and then continue
with 1000 more retries.
  According to the data sheet a state transition is supposed to take
up to 2 bus cycles. Only time I can see that this would take longer
time are all error states, but the data sheet is not very clear
regarding this.

* qup_i2c_wait_idle() reads the status register up to 1000 times,
hoping the fifo gets drained and the bus go idle, if that fails it
sleeps for the time we expect it to take to drain a full fifo and then
loops another 1000 times. This waits for the fifo to have drained and
the bus to go idle. On a read we get to this state if we issue the
write and then hit the error state, so we would reset the entire
block. On write we will only wait for the buffer not to be full before
returning.

* qup_i2c_wait_clock_ready() waits up to 300 bus-clocks for the i2c
bus to go idle or forced low, I don't know why it retries 300 times.
This is called at the end of a write, possibly to wait for the fifo to
drain.


All three loops are in line with how it's been in codeaurora since the
beginning of time, but I at least need to figure out some good names
for those "magic numbers".

Sure. I have keep them this way, just because I don't have information
for internal trickery of the block.

I'll continue to talk to the Qualcomm guys to see if we can figure out
anything regarding the expected timings of those operations and I'll
send out a new version when we have something saner.

Regards,
Bjorn