2019-05-28 10:57:06 -06:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2013-01-25 16:44:00 -07:00
|
|
|
/*
|
|
|
|
|
* STMicroelectronics sensors buffer library driver
|
|
|
|
|
*
|
|
|
|
|
* Copyright 2012-2013 STMicroelectronics Inc.
|
|
|
|
|
*
|
|
|
|
|
* Denis Ciocca <denis.ciocca@st.com>
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
#include <linux/iio/iio.h>
|
|
|
|
|
#include <linux/iio/trigger.h>
|
|
|
|
|
#include <linux/interrupt.h>
|
|
|
|
|
#include <linux/iio/buffer.h>
|
|
|
|
|
#include <linux/iio/trigger_consumer.h>
|
|
|
|
|
#include <linux/iio/triggered_buffer.h>
|
|
|
|
|
#include <linux/irqreturn.h>
|
|
|
|
|
|
|
|
|
|
#include <linux/iio/common/st_sensors.h>
|
|
|
|
|
|
|
|
|
|
|
2016-04-19 03:18:38 -06:00
|
|
|
static int st_sensors_get_buffer_element(struct iio_dev *indio_dev, u8 *buf)
|
2013-01-25 16:44:00 -07:00
|
|
|
{
|
2016-06-27 04:38:52 -06:00
|
|
|
int i;
|
2013-01-25 16:44:00 -07:00
|
|
|
struct st_sensor_data *sdata = iio_priv(indio_dev);
|
2013-06-03 08:58:00 -06:00
|
|
|
unsigned int num_data_channels = sdata->num_data_channels;
|
2013-01-25 16:44:00 -07:00
|
|
|
|
2016-06-27 04:38:52 -06:00
|
|
|
for_each_set_bit(i, indio_dev->active_scan_mask, num_data_channels) {
|
|
|
|
|
const struct iio_chan_spec *channel = &indio_dev->channels[i];
|
2016-11-16 14:15:28 -07:00
|
|
|
unsigned int bytes_to_read =
|
|
|
|
|
DIV_ROUND_UP(channel->scan_type.realbits +
|
|
|
|
|
channel->scan_type.shift, 8);
|
2016-06-27 04:38:52 -06:00
|
|
|
unsigned int storage_bytes =
|
|
|
|
|
channel->scan_type.storagebits >> 3;
|
|
|
|
|
|
|
|
|
|
buf = PTR_ALIGN(buf, storage_bytes);
|
|
|
|
|
if (sdata->tf->read_multiple_byte(&sdata->tb, sdata->dev,
|
|
|
|
|
channel->address,
|
|
|
|
|
bytes_to_read, buf,
|
|
|
|
|
sdata->multiread_bit) <
|
|
|
|
|
bytes_to_read)
|
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
|
|
/* Advance the buffer pointer */
|
|
|
|
|
buf += storage_bytes;
|
2013-01-25 16:44:00 -07:00
|
|
|
}
|
|
|
|
|
|
2016-06-27 04:38:52 -06:00
|
|
|
return 0;
|
2013-01-25 16:44:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
irqreturn_t st_sensors_trigger_handler(int irq, void *p)
|
|
|
|
|
{
|
|
|
|
|
int len;
|
|
|
|
|
struct iio_poll_func *pf = p;
|
|
|
|
|
struct iio_dev *indio_dev = pf->indio_dev;
|
|
|
|
|
struct st_sensor_data *sdata = iio_priv(indio_dev);
|
iio: st_sensors: switch to a threaded interrupt
commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded
("iio: st_sensors: verify interrupt event to status") caused
a regression when reading ST sensors from a HRTimer trigger
rather than the intrinsic interrupts: the HRTimer may
trigger faster than the sensor provides new values, and
as the check against new values available as a cause of
the interrupt trigger was done in the poll function,
this would bail out of the HRTimer interrupt with
IRQ_NONE.
So clearly we need to only check the new values available
from the proper interrupt handler and not from the poll
function, which should rather just read the raw values
from the registers, put them into the buffer and be happy.
To achieve this: switch the ST Sensors over to using a true
threaded interrupt handler.
In the interrupt thread, check if new values are available,
else yield to the (potential) next device on the same
interrupt line to check the registers. If the interrupt
was ours, proceed to poll the values.
Instead of relying on iio_trigger_generic_data_rdy_poll() as
a top half to wake up the thread that polls the sensor for
new data, have the thread call iio_trigger_poll_chained()
after determining that is is the proper source of the
interrupt. This is modelled on drivers/iio/accel/mma8452.c
which is already using a properly threaded interrupt handler.
In order to get the same precision in timestamps as
previously, where samples would be timestamped in the
poll function pf->timestamp when calling
iio_trigger_generic_data_rdy_poll() we introduce a
local timestamp in the sensor data, set it in the top half
(fastpath) of the interrupt handler and provide that to the
core when calling iio_push_to_buffers_with_timestamp().
Additionally: if the active scanmask is not set for the
sensor no IRQs should be enabled and we need to bail out
with IRQ_NONE. This can happen if spurious IRQs fire when
installing the threaded interrupt handler.
Tested with hard interrupt triggers on LIS331DL, then also
tested with hrtimers on the same sensor by creating a 75Hz
HRTimer and using it to poll the sensor.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Jonathan Cameron <jic23@kernel.org>
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-21 12:43:16 -06:00
|
|
|
s64 timestamp;
|
2013-01-25 16:44:00 -07:00
|
|
|
|
iio: st_sensors: harden interrupt handling
Leonard Crestez observed the following phenomenon: when using
hard interrupt triggers (the DRDY line coming out of an ST
sensor) sometimes a new value would arrive while reading the
previous value, due to latencies in the system.
We discovered that the ST hardware as far as can be observed
is designed for level interrupts: the DRDY line will be held
asserted as long as there are new values coming. The interrupt
handler should be re-entered until we're out of values to
handle from the sensor.
If interrupts were handled as occurring on the edges (usually
low-to-high) new values could appear and the line be held
asserted after that, and these values would be missed, the
interrupt handler would also lock up as new data was
available, but as no new edges occurs on the DRDY signal,
nothing happens: the edge detector only detects edges.
To counter this, do the following:
- Accept interrupt lines to be flagged as level interrupts
using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line
is marked like this (in the device tree node or ACPI
table or similar) it will be utilized as a level IRQ.
We mark the line with IRQF_ONESHOT and mask the IRQ
while processing a sample, then the top half will be
entered again if new values are available.
- If we are flagged as using edge interrupts with
IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove
IRQF_ONESHOT so that the interrupt line is not
masked while running the thread part of the interrupt.
This way we will never miss an interrupt, then introduce
a loop that polls the data ready registers repeatedly
until no new samples are available, then exit the
interrupt handler. This way we know no new values are
available when the interrupt handler exits and
new (edge) interrupts will be triggered when data arrives.
Take some extra care to update the timestamp in the poll
loop if this happens. The timestamp will not be 100%
perfect, but it will at least be closer to the actual
events. Usually the extra poll loop will handle the new
samples, but once in a blue moon, we get a new IRQ
while exiting the loop, before returning from the
thread IRQ bottom half with IRQ_HANDLED. On these rare
occasions, the removal of IRQF_ONESHOT means the
interrupt will immediately fire again.
- If no interrupt type is indicated from the DT/ACPI,
choose IRQF_TRIGGER_RISING as default, as this is necessary
for legacy boards.
Tested successfully on the LIS331DL and L3G4200D by setting
sampling frequency to 400Hz/800Hz and stressing the system:
extra reads in the threaded interrupt handler occurs.
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Tested-by: Crestez Dan Leonard <cdleonard@gmail.com>
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-06-29 07:14:42 -06:00
|
|
|
/*
|
|
|
|
|
* If we do timetamping here, do it before reading the values, because
|
|
|
|
|
* once we've read the values, new interrupts can occur (when using
|
|
|
|
|
* the hardware trigger) and the hw_timestamp may get updated.
|
|
|
|
|
* By storing it in a local variable first, we are safe.
|
|
|
|
|
*/
|
2016-09-01 02:27:18 -06:00
|
|
|
if (iio_trigger_using_own(indio_dev))
|
iio: st_sensors: switch to a threaded interrupt
commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded
("iio: st_sensors: verify interrupt event to status") caused
a regression when reading ST sensors from a HRTimer trigger
rather than the intrinsic interrupts: the HRTimer may
trigger faster than the sensor provides new values, and
as the check against new values available as a cause of
the interrupt trigger was done in the poll function,
this would bail out of the HRTimer interrupt with
IRQ_NONE.
So clearly we need to only check the new values available
from the proper interrupt handler and not from the poll
function, which should rather just read the raw values
from the registers, put them into the buffer and be happy.
To achieve this: switch the ST Sensors over to using a true
threaded interrupt handler.
In the interrupt thread, check if new values are available,
else yield to the (potential) next device on the same
interrupt line to check the registers. If the interrupt
was ours, proceed to poll the values.
Instead of relying on iio_trigger_generic_data_rdy_poll() as
a top half to wake up the thread that polls the sensor for
new data, have the thread call iio_trigger_poll_chained()
after determining that is is the proper source of the
interrupt. This is modelled on drivers/iio/accel/mma8452.c
which is already using a properly threaded interrupt handler.
In order to get the same precision in timestamps as
previously, where samples would be timestamped in the
poll function pf->timestamp when calling
iio_trigger_generic_data_rdy_poll() we introduce a
local timestamp in the sensor data, set it in the top half
(fastpath) of the interrupt handler and provide that to the
core when calling iio_push_to_buffers_with_timestamp().
Additionally: if the active scanmask is not set for the
sensor no IRQs should be enabled and we need to bail out
with IRQ_NONE. This can happen if spurious IRQs fire when
installing the threaded interrupt handler.
Tested with hard interrupt triggers on LIS331DL, then also
tested with hrtimers on the same sensor by creating a 75Hz
HRTimer and using it to poll the sensor.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Jonathan Cameron <jic23@kernel.org>
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-21 12:43:16 -06:00
|
|
|
timestamp = sdata->hw_timestamp;
|
|
|
|
|
else
|
2016-03-09 11:05:49 -07:00
|
|
|
timestamp = iio_get_time_ns(indio_dev);
|
2016-03-24 07:18:05 -06:00
|
|
|
|
2013-01-25 16:44:00 -07:00
|
|
|
len = st_sensors_get_buffer_element(indio_dev, sdata->buffer_data);
|
|
|
|
|
if (len < 0)
|
|
|
|
|
goto st_sensors_get_buffer_element_error;
|
|
|
|
|
|
2013-09-19 06:59:00 -06:00
|
|
|
iio_push_to_buffers_with_timestamp(indio_dev, sdata->buffer_data,
|
iio: st_sensors: switch to a threaded interrupt
commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded
("iio: st_sensors: verify interrupt event to status") caused
a regression when reading ST sensors from a HRTimer trigger
rather than the intrinsic interrupts: the HRTimer may
trigger faster than the sensor provides new values, and
as the check against new values available as a cause of
the interrupt trigger was done in the poll function,
this would bail out of the HRTimer interrupt with
IRQ_NONE.
So clearly we need to only check the new values available
from the proper interrupt handler and not from the poll
function, which should rather just read the raw values
from the registers, put them into the buffer and be happy.
To achieve this: switch the ST Sensors over to using a true
threaded interrupt handler.
In the interrupt thread, check if new values are available,
else yield to the (potential) next device on the same
interrupt line to check the registers. If the interrupt
was ours, proceed to poll the values.
Instead of relying on iio_trigger_generic_data_rdy_poll() as
a top half to wake up the thread that polls the sensor for
new data, have the thread call iio_trigger_poll_chained()
after determining that is is the proper source of the
interrupt. This is modelled on drivers/iio/accel/mma8452.c
which is already using a properly threaded interrupt handler.
In order to get the same precision in timestamps as
previously, where samples would be timestamped in the
poll function pf->timestamp when calling
iio_trigger_generic_data_rdy_poll() we introduce a
local timestamp in the sensor data, set it in the top half
(fastpath) of the interrupt handler and provide that to the
core when calling iio_push_to_buffers_with_timestamp().
Additionally: if the active scanmask is not set for the
sensor no IRQs should be enabled and we need to bail out
with IRQ_NONE. This can happen if spurious IRQs fire when
installing the threaded interrupt handler.
Tested with hard interrupt triggers on LIS331DL, then also
tested with hrtimers on the same sensor by creating a 75Hz
HRTimer and using it to poll the sensor.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Giuseppe Barba <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Crestez Dan Leonard <cdleonard@gmail.com>
Tested-by: Jonathan Cameron <jic23@kernel.org>
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-05-21 12:43:16 -06:00
|
|
|
timestamp);
|
2013-01-25 16:44:00 -07:00
|
|
|
|
|
|
|
|
st_sensors_get_buffer_element_error:
|
|
|
|
|
iio_trigger_notify_done(indio_dev->trig);
|
|
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(st_sensors_trigger_handler);
|
|
|
|
|
|
|
|
|
|
MODULE_AUTHOR("Denis Ciocca <denis.ciocca@st.com>");
|
|
|
|
|
MODULE_DESCRIPTION("STMicroelectronics ST-sensors buffer");
|
|
|
|
|
MODULE_LICENSE("GPL v2");
|