[uClinux-dev] 2.6.29 unexplained delay seen in i2c-imx.c driver

[Priscilla Wong]

Can someone help me on an issue I am seeing on my i2c-imx driver for
uClinux 2.6.29?

Attached is a scope capture of an i2c read operation. In the capture,
yellow is clock, green is data, blue and pink are both gpios I am using
for debugging. It can be seen that there is a 300 us delay after master
writes to the slave address. The transfer is complete when the interrupt
arrives and waitqueue is woken up. The pink gpio fires high during the
transfer complete call (i2c_imx_trx_complete) after the slave address is
written. The blue gpio fires high during the queue wake up call in the
ISR (i2c_imx_isr). When looking at this capture, my first inclination is
to bump the interrupt level and priority, hoping it will speed up the
ISR but it had no effect on the delay.

Any ideas what is causing this delay?

Thanks,
Priscilla


-------------- next part --------------
A non-text attachment was scrubbed...
Name: scope_14.png
Type: image/png
Size: 33761 bytes
Desc: not available
URL: <Loading Image...>

[Steven King]

Post by Priscilla Wong
Can someone help me on an issue I am seeing on my i2c-imx driver for
uClinux 2.6.29?
Attached is a scope capture of an i2c read operation. In the capture,
yellow is clock, green is data, blue and pink are both gpios I am using
for debugging. It can be seen that there is a 300 us delay after master
writes to the slave address. The transfer is complete when the interrupt
arrives and waitqueue is woken up. The pink gpio fires high during the
transfer complete call (i2c_imx_trx_complete) after the slave address is
written. The blue gpio fires high during the queue wake up call in the
ISR (i2c_imx_isr). When looking at this capture, my first inclination is
to bump the interrupt level and priority, hoping it will speed up the
ISR but it had no effect on the delay.
Any ideas what is causing this delay?

That looks similar to an issue with the original version of my i2c-coldfire
driver; the scheduler simply can't reschedule tasks any faster than that.
The fix was to have the isr process the next byte in the transfer and only
send the completion when the entire message was transfered.

[Priscilla Wong]

Post by Steven King

Post by Priscilla Wong
Can someone help me on an issue I am seeing on my i2c-imx driver for
uClinux 2.6.29?
Attached is a scope capture of an i2c read operation. In the capture,
yellow is clock, green is data, blue and pink are both gpios I am using
for debugging. It can be seen that there is a 300 us delay after master
writes to the slave address. The transfer is complete when the interrupt
arrives and waitqueue is woken up. The pink gpio fires high during the
transfer complete call (i2c_imx_trx_complete) after the slave address is
written. The blue gpio fires high during the queue wake up call in the
ISR (i2c_imx_isr). When looking at this capture, my first inclination is
to bump the interrupt level and priority, hoping it will speed up the
ISR but it had no effect on the delay.
Any ideas what is causing this delay?

That looks similar to an issue with the original version of my i2c-coldfire
driver; the scheduler simply can't reschedule tasks any faster than that.
The fix was to have the isr process the next byte in the transfer and only
send the completion when the entire message was transfered.

Thanks for your input!

Would changing the implementation to polling based be the answer given
that i2c-mcf did not have this issue? I've attached a scope image of a
read access with i2c-mcf (i2c-mcf-i2cget.png). However if switching
i2c-imx to polling based, the data transferring bit (ICF) also suffers
from this delay too. It is not set till 228us after the 9th clock cycle
(See attached scope15.png image, cursor X1 is the 9th clock cycle and X2
is when ICF is set). Any ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scope_15.png
Type: image/png
Size: 33749 bytes
Desc: not available
URL: <Loading Image...>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2c-mcf-i2cget.png
Type: image/png
Size: 33827 bytes
Desc: not available
URL: <Loading Image...>

[Steven King]

Post by Priscilla Wong

Post by Steven King

Post by Priscilla Wong
Can someone help me on an issue I am seeing on my i2c-imx driver for
uClinux 2.6.29?
Attached is a scope capture of an i2c read operation. In the capture,
yellow is clock, green is data, blue and pink are both gpios I am using
for debugging. It can be seen that there is a 300 us delay after master
writes to the slave address. The transfer is complete when the interrupt
arrives and waitqueue is woken up. The pink gpio fires high during the
transfer complete call (i2c_imx_trx_complete) after the slave address is
written. The blue gpio fires high during the queue wake up call in the
ISR (i2c_imx_isr). When looking at this capture, my first inclination is
to bump the interrupt level and priority, hoping it will speed up the
ISR but it had no effect on the delay.
Any ideas what is causing this delay?

That looks similar to an issue with the original version of my
i2c-coldfire driver; the scheduler simply can't reschedule tasks any
faster than that. The fix was to have the isr process the next byte in
the transfer and only send the completion when the entire message was
transfered.

Thanks for your input!
Would changing the implementation to polling based be the answer given
that i2c-mcf did not have this issue? I've attached a scope image of a
read access with i2c-mcf (i2c-mcf-i2cget.png). However if switching
i2c-imx to polling based, the data transferring bit (ICF) also suffers
from this delay too. It is not set till 228us after the 9th clock cycle
(See attached scope15.png image, cursor X1 is the 9th clock cycle and X2
is when ICF is set). Any ideas?

Sorry, I'm not familiar with those drivers but I would guess its something
similar, a context switch or superfluous udelay somewher.