On Tue, May 3, 2016 at 7:58 PM, Crestez Dan Leonard <cdleonard@xxxxxxxxx> wrote:
> On 03/24/2016 03:18 PM, Linus Walleij wrote:
>> This makes all ST sensor drivers check that they actually have
>> new data available for the requested channel(s) before claiming
>> an IRQ, by reading the status register (which is conveniently
>> the same for all ST sensors) and check that the channel has new
>> data before proceeding to read it and fill the buffer.
>>
>> This way sensors can share an interrupt line: it can be flaged
>> as shared and then the sensor that did not fire will return
>> NO_IRQ, and the sensor that fired will handle the IRQ and
>> return IRQ_HANDLED.
>>
(...)
>> + /* If we have a status register, check if this IRQ came from us */
>> + if (sdata->sensor_settings->drdy_irq.addr_stat_drdy) {
>> + u8 status;
>> +
>> + len = sdata->tf->read_byte(&sdata->tb, sdata->dev,
>> + sdata->sensor_settings->drdy_irq.addr_stat_drdy,
>> + &status);
>> + if (len < 0)
>> + dev_err(sdata->dev, "could not read channel status\n");
>> +
>> + /*
>> + * If this was not caused by any channels on this sensor,
>> + * return IRQ_NONE
>> + */
>> + if (!(status & (u8)indio_dev->active_scan_mask[0]))
>> + return IRQ_NONE;
>> + }
>>
> This seems to break software trigger mode when the timer frequency is
> higher that the device polling frequency. In that case it is possible to
> poll multiple times between updates and the first time this happens
> further updates hang.
OK I understand This is a hard IRQ handler for DRDY.
We need to avoid checking the status register with software triggers.
I guess it's possible to see in struct iio_dev whether we get called
from a software trigger?
Can you give me instructions on how to reproduce the error so I
can verify that I fix it? I never managed to get software triggers
to work :(
> Even with hardware triggers: are you sure this is correct? Shouldn't
> iio_trigger_notify_done still get called even when there is nothing to do?
No then the (hardware) IRQ can have come in from some other
device sharing the line with the peripheral and we need to return
IRQ_NONE. It's not our interrupt.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
