A IIO trigger problem/bug.

A IIO trigger problem/bug.

[Ge Gao]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Dear all,
    I met a strange problem concerning IIO driver. I wrote a driver that
has trigger, ring buffer, just the standard way of doing things. It
sometimes runs OK. However, I found sometimes, the trigger is NOT triggered
at all. I am using a hardware interrupt to trigger a threaded ISR and
post-ISR. I can see the interrupt coming correctly. By using "cat
/proc/interrupts", I can see that the number of triggers stays the same
while the number of interrupt increases steadily.
   I am using "iio_trigger_generic_data_rdy_poll" in the trigger. In the
post ISR, I am using "iio_trigger_notify_done".
I check the IIO trigger code.  The trigger uses "trig->use_count" to do
things. If "trig->use_count" is not zero, nothing will happen. Where the
only place trig->use_count decreases is in "iio_trigger_notify_done". It is
possible that, if system is busy, that post ISR is NOT scheduled, such that
trig->use_count will NOT decrease. This would defeat all the mechanism of
trigger.  Or there are other possibilities that would fail?
   Thanks.

Best regards,

Ge GAO

[-- Attachment #2: Type: text/html, Size: 1191 bytes --]

Re: A IIO trigger problem/bug.

[Jonathan Cameron]

On 5/31/2012 4:56 PM, Ge Gao wrote:
>
>     I met a strange problem concerning IIO driver. I wrote a driver 
> that has trigger, ring buffer,just the standard way of doing things. 
> It sometimes runs OK. However, I found sometimes, the trigger is NOT 
> triggered at all. I am using a hardware interrupt to trigger a 
> threaded ISR and post-ISR. I can see the interrupt coming correctly. 
> By using "cat /proc/interrupts", I can see that the number of triggers 
> stays the same while the number of interrupt increases steadily. 
It's been a while since I looked at this corner, but IIRC the basic 
principal is to prevent the driver
read out code from being reentrant. Thus if your trigger is occuring 
faster than the driver is
capable of reading from the device then triggers will be dropped.
It's possible that we have a bug in there that means it is not 
succesfully recovering from the trigger being dropped.

One thought would be that you weren't clearing the interrupt unless a 
read occurs, but that doesn't seem
to be the case here given you are seeing /proc/interrupts continue to 
increase...

The driver controls masking (typically through IRQF_ONESHOT) of an 
interrupt that is in turn fed by a second
interrupt handler - the one in your driver handling the actual hardware 
interrupt.

I can't immediately spot why trig->usecount would be wrong.   Just as a 
test could you drop the test for it
entirely and see if that makes things work as expected?  That will break 
having multiple users of the trigger,
but might give us some clues as to what is happening.  Otherwise, please 
add some printk's to the relevant
places and lets see what is happening.  With your usecase 
trig->use_count should only ever be 0 or 1
and if it is still 1 in iio_trigger_poll, we'll have some clue what is 
happening...