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.
>
> diff --git a/drivers/iio/common/st_sensors/st_sensors_buffer.c b/drivers/iio/common/st_sensors/st_sensors_buffer.c
> index 2ce0d2a3f855..c55898543a47 100644
> --- a/drivers/iio/common/st_sensors/st_sensors_buffer.c
> +++ b/drivers/iio/common/st_sensors/st_sensors_buffer.c
> @@ -58,6 +58,24 @@ irqreturn_t st_sensors_trigger_handler(int irq, void *p)
> struct iio_dev *indio_dev = pf->indio_dev;
> struct st_sensor_data *sdata = iio_priv(indio_dev);
>
> + /* 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.
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?
--
Regards,
Leonard
--
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
