<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/iio/common, branch v4.7.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>iio: st_sensors: Disable DRDY at init time</title>
<updated>2016-05-29T19:27:16+00:00</updated>
<author>
<name>Crestez Dan Leonard</name>
<email>leonard.crestez@intel.com</email>
</author>
<published>2016-05-13T18:43:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=99147606155f09feccac67c65387dc62260b749b'/>
<id>99147606155f09feccac67c65387dc62260b749b</id>
<content type='text'>
This fixes odd behavior after reboot.

The fact that we set the device to powerdown mode is not sufficient to
prevent DRDY being active because we might still have an unread sample.

Even if powerdown was sufficient keeping DRDY disabled while trigger is
not active is a good idea.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Crestez Dan Leonard &lt;leonard.crestez@intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes odd behavior after reboot.

The fact that we set the device to powerdown mode is not sufficient to
prevent DRDY being active because we might still have an unread sample.

Even if powerdown was sufficient keeping DRDY disabled while trigger is
not active is a good idea.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Crestez Dan Leonard &lt;leonard.crestez@intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: Init trigger before irq request</title>
<updated>2016-05-29T19:25:27+00:00</updated>
<author>
<name>Crestez Dan Leonard</name>
<email>leonard.crestez@intel.com</email>
</author>
<published>2016-05-13T18:43:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff05916f94f912b25e8efcf9b02c10d481977bab'/>
<id>ff05916f94f912b25e8efcf9b02c10d481977bab</id>
<content type='text'>
This fixes a possible race where an interrupt arrives before complete
initialization and crashes because iio_trigger_get_drvdata returns NULL.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Crestez Dan Leonard &lt;leonard.crestez@intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a possible race where an interrupt arrives before complete
initialization and crashes because iio_trigger_get_drvdata returns NULL.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Crestez Dan Leonard &lt;leonard.crestez@intel.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: switch to a threaded interrupt</title>
<updated>2016-05-29T19:21:41+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2016-05-21T18:43:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65925b65ed98ffdb277cf5ea1af45731dac0b30b'/>
<id>65925b65ed98ffdb277cf5ea1af45731dac0b30b</id>
<content type='text'>
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-&gt;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 &lt;linus.walleij@linaro.org&gt;
Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Reported-by: Crestez Dan Leonard &lt;cdleonard@gmail.com&gt;
Tested-by: Crestez Dan Leonard &lt;cdleonard@gmail.com&gt;
Tested-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-&gt;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 &lt;linus.walleij@linaro.org&gt;
Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Reported-by: Crestez Dan Leonard &lt;cdleonard@gmail.com&gt;
Tested-by: Crestez Dan Leonard &lt;cdleonard@gmail.com&gt;
Tested-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status")
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: support open drain mode</title>
<updated>2016-04-19T18:58:13+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2016-04-14T08:45:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0e6f6871a1591f4bb0971809c45bc91a991f1967'/>
<id>0e6f6871a1591f4bb0971809c45bc91a991f1967</id>
<content type='text'>
Some types of ST Sensors can be connected to the same IRQ line
as other peripherals using open drain. Add a device tree binding
and a sensor data property to flip the right bit in the interrupt
control register to enable open drain mode on the INT line.

If the line is set to be open drain, also tag on IRQF_SHARED
to the IRQ flags when requesting the interrupt, as the whole
point of using open drain interrupt lines is to share them with
more than one peripheral (wire-or).

Cc: devicetree@vger.kernel.org
Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Acked-by: Rob Herring &lt;rob@kernel.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some types of ST Sensors can be connected to the same IRQ line
as other peripherals using open drain. Add a device tree binding
and a sensor data property to flip the right bit in the interrupt
control register to enable open drain mode on the INT line.

If the line is set to be open drain, also tag on IRQF_SHARED
to the IRQ flags when requesting the interrupt, as the whole
point of using open drain interrupt lines is to share them with
more than one peripheral (wire-or).

Cc: devicetree@vger.kernel.org
Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Acked-by: Rob Herring &lt;rob@kernel.org&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: verify interrupt event to status</title>
<updated>2016-04-19T18:58:12+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2016-03-24T13:18:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=97865fe41322d83dac4373fe0a0de5b1a1b318c5'/>
<id>97865fe41322d83dac4373fe0a0de5b1a1b318c5</id>
<content type='text'>
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.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: read each channel individually</title>
<updated>2016-04-19T18:58:11+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2016-03-24T13:18:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6436db37b4a5da1ae1f381e4791e17e2236fd276'/>
<id>6436db37b4a5da1ae1f381e4791e17e2236fd276</id>
<content type='text'>
The current buffer read code tries to optimize reads from the
sensor data registers by issuing a single read operation across
all the indata registers.

This doesn't work: when the LIS331DL accelerometer sensor is
configured to open drain, active low interrupt mode, this will
just clear the XDA (X-axis data available) bit in the STATUS_REG
register (0x27), while YDA, ZDA and even ZYXDA remain set to 1,
and the internal logic of the sensor holds the DRDY (INT1) line
asserted (the value of the status register is 0xee).

If we instead issue one read operation per enabled channel
(X, Y, Z) things start working and we can use open drain and
active low interrupts.

Note that a backported patch fixing this issue will be heading
via the fixes branch but changes in this file already in staging-next
will make that patch 'look' rather different.  The code in here
is the correct one when that clash hits.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current buffer read code tries to optimize reads from the
sensor data registers by issuing a single read operation across
all the indata registers.

This doesn't work: when the LIS331DL accelerometer sensor is
configured to open drain, active low interrupt mode, this will
just clear the XDA (X-axis data available) bit in the STATUS_REG
register (0x27), while YDA, ZDA and even ZYXDA remain set to 1,
and the internal logic of the sensor holds the DRDY (INT1) line
asserted (the value of the status register is 0xee).

If we instead issue one read operation per enabled channel
(X, Y, Z) things start working and we can use open drain and
active low interrupts.

Note that a backported patch fixing this issue will be heading
via the fixes branch but changes in this file already in staging-next
will make that patch 'look' rather different.  The code in here
is the correct one when that clash hits.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: common: hid-sensors: use tab for indention</title>
<updated>2016-04-16T12:39:26+00:00</updated>
<author>
<name>Slawomir Stepien</name>
<email>sst@poczta.fm</email>
</author>
<published>2016-04-14T19:36:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d23057e0cadc465911968a4d3f8b0b556f545b6e'/>
<id>d23057e0cadc465911968a4d3f8b0b556f545b6e</id>
<content type='text'>
This fixes the error reported by checkpatch.pl:

ERROR: code indent should use tabs where possible

Signed-off-by: Slawomir Stepien &lt;sst@poczta.fm&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the error reported by checkpatch.pl:

ERROR: code indent should use tabs where possible

Signed-off-by: Slawomir Stepien &lt;sst@poczta.fm&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: common: ms_sensors: use tab for indention</title>
<updated>2016-04-16T12:39:25+00:00</updated>
<author>
<name>Slawomir Stepien</name>
<email>sst@poczta.fm</email>
</author>
<published>2016-04-14T19:36:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f6aa8eaf5d301b213f4660d1a37b44b5f1c2c458'/>
<id>f6aa8eaf5d301b213f4660d1a37b44b5f1c2c458</id>
<content type='text'>
This fixes the error reported by checkpatch.pl:

ERROR: code indent should use tabs where possible

Signed-off-by: Slawomir Stepien &lt;sst@poczta.fm&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the error reported by checkpatch.pl:

ERROR: code indent should use tabs where possible

Signed-off-by: Slawomir Stepien &lt;sst@poczta.fm&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: simplify buffer address handling</title>
<updated>2016-03-28T07:51:39+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2016-03-24T13:18:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e6e45420f41fc613569e8bb6d15e0472dc0ea1ab'/>
<id>e6e45420f41fc613569e8bb6d15e0472dc0ea1ab</id>
<content type='text'>
The driver goes to some length to dynamically allocate an array
to hold the channel addresses. However no ST sensor has more than
three channels (x, y, z at most). Instead of kmalloc():ing and
kfree():in the address array, just use a fixed array of three
elements.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The driver goes to some length to dynamically allocate an array
to hold the channel addresses. However no ST sensor has more than
three channels (x, y, z at most). Instead of kmalloc():ing and
kfree():in the address array, just use a fixed array of three
elements.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Acked-by: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>iio: st_sensors: support active-low interrupts</title>
<updated>2016-01-10T12:35:32+00:00</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2015-11-19T09:15:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a9fd053b56c6bb14972ab7a19da0b575fe4c5d66'/>
<id>a9fd053b56c6bb14972ab7a19da0b575fe4c5d66</id>
<content type='text'>
Most ST MEMS Sensors that support interrupts can also handle sending
an active low interrupt, i.e. going from high to low on data ready
(or other interrupt) and thus triggering on a falling edge to the
interrupt controller.

Set up logic to inspect the interrupt line we get for a sensor: if
it is triggering on rising edge, leave everything alone, but if it
triggers on falling edges, set up active low, and if unsupported
configurations appear: warn with errors and reconfigure the interrupt
to a rising edge, which all interrupt generating sensors support.

Create a local header for st_sensors_core.h to share functions
between the sensor core and the trigger setup code.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most ST MEMS Sensors that support interrupts can also handle sending
an active low interrupt, i.e. going from high to low on data ready
(or other interrupt) and thus triggering on a falling edge to the
interrupt controller.

Set up logic to inspect the interrupt line we get for a sensor: if
it is triggering on rising edge, leave everything alone, but if it
triggers on falling edges, set up active low, and if unsupported
configurations appear: warn with errors and reconfigure the interrupt
to a rising edge, which all interrupt generating sensors support.

Create a local header for st_sensors_core.h to share functions
between the sensor core and the trigger setup code.

Cc: Giuseppe Barba &lt;giuseppe.barba@st.com&gt;
Cc: Denis Ciocca &lt;denis.ciocca@st.com&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
