[PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller

[Ivan T. Ivanov]

Hi Bjorn,

On Wed, 2014-01-29 at 08:32 -0800, Bjorn Andersson wrote: 
> On Wed, Jan 29, 2014 at 12:14 AM, Ivan T. Ivanov <iivanov at mm-sol.com> wrote:
> >
> > Hi Bjorn,
> >
> > On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:
> >> 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.

> 
> 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.

Thanks, 
Ivan


> 
> Regards,
> Bjorn