linux-stable.git/drivers/iio/common, branch linux-4.8.y

iio: st_sensors: fix scale configuration for h3lis331dl

2016-11-18T09:51:48+00:00

commit d304286abbbe7ed6228a553a56ba054e900907eb upstream.

fix scale configuration/parsing for h3lis331dl accel driver
when sensitivity is higher than 1(m/s^2)/digit

Signed-off-by: Lorenzo Bianconi 
Fixes: 1e52fefc9b0c ("iio: accel: Add support for the h3lis331dl accelerometer")
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: hid-sensors: Increase the precision of scale to fix wrong reading interpretation.

2016-11-18T09:51:47+00:00

commit 6f77199e9e4b84340c751c585691d7642a47d226 upstream.

While testing, it was observed that on some platforms the scale value
from iio sysfs for gyroscope is always 0 (E.g. Yoga 260). This results
in the final angular velocity component values to be zeros.

This is caused by insufficient precision of scale value displayed in sysfs.
If the precision is changed to nano from current micro, then this is
sufficient to display the scale value on this platform.
Since this can be a problem for all other HID sensors, increase scale
precision of all HID sensors to nano from current micro.

Results on Yoga 260:

name		scale before	scale now
--------------------------------------------
gyro_3d		0.000000	0.000000174
als			0.001000	0.001000000
magn_3d		0.000001	0.000001000
accel_3d		0.000009	0.000009806

Signed-off-by: Song Hongyan 
Acked-by: Srinivas Pandruvada 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: fix pressure data output unit in hid-sensor-attributes

2016-09-03T16:09:58+00:00

According to IIO ABI definition, IIO_PRESSURE data output unit is
kilopascal:
http://lxr.free-electrons.com/source/Documentation/ABI/testing/sysfs-bus-iio

This patch fix output unit of HID pressure sensor IIO driver from pascal to
kilopascal to follow IIO ABI definition.

Signed-off-by: Kweh, Hock Leong 
Reviewed-by: Srinivas Pandruvada 
Cc: 
Signed-off-by: Jonathan Cameron

iio:st_sensors: align on storagebits boundaries

2016-07-04T17:07:45+00:00

Ensure triggered buffering memory accesses are properly aligned on per
channel storagebits boundaries.

Signed-off-by: Gregor Boirie 
Tested-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: accel: st_accel: Add lis3l02dq support

2016-07-04T17:07:44+00:00

Time to finally kill off the venerable (it was one of my first drivers)
lis3l02dq driver in favour of adding support in the st sensors framework.

This does loose us the event support that driver always had, but I think
that will reappear at some point and in the meantime the maintenance
advantages of dropping the 'special' driver for this one part outweigh
the issues.

It's worth noting this part is ancient and I may well be the only person
who still has any on hardware running recent kernels.

It has a few 'quirks'.
 - No WAI register so that just became optional.
 - A BDU option that really does block updates.  Completely.
   Whatever you do, you don't get any more data with it set.
   It is documented the same as more modern parts but I presume they
   are actually clearing for updates after a read of both bytes!
 - Fixed scale.
 - It's too quick.  Even at slowest rate (280Hz) I can't read out fast
   enough on my board (stargate 2) to beat new data coming in. Linus'
   repeat read patch doesn't help in this case. It just means I get 10
   readings before dying... So in reality this will get used with
   software triggers only unless someone has this long out of production
   device on a quick board.

Signed-off-by: Jonathan Cameron 
Reviewed-by: Linus Walleij 
Cc: Denis CIOCCA 
Cc: Crestez Dan Leonard 
Signed-off-by: Jonathan Cameron

iio: st_sensors: harden interrupt handling

2016-07-02T19:40:15+00:00

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 
Cc: Denis Ciocca 
Tested-by: Crestez Dan Leonard 
Reported-by: Crestez Dan Leonard 
Signed-off-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio:core: timestamping clock selection support

2016-06-30T18:41:38+00:00

Adds a new per-device sysfs attribute "current_timestamp_clock" to allow
userspace to select a particular POSIX clock for buffered samples and
events timestamping.

Following clocks, as listed in clock_gettime(2), are supported:
CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW,
CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and
CLOCK_TAI.

Signed-off-by: Gregor Boirie 
Acked-by: Sanchayan Maity 
Signed-off-by: Jonathan Cameron

Merge 4.7-rc4 into staging-next

2016-06-20T15:25:44+00:00

We want the fixes in here, and we can resolve a merge issue in
drivers/iio/industrialio-trigger.c

Signed-off-by: Greg Kroah-Hartman

iio: st_sensors: Disable DRDY at init time

2016-05-29T19:27:16+00:00

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 
Cc: Denis Ciocca 
Signed-off-by: Crestez Dan Leonard 
Reviewed-by: Linus Walleij 
Signed-off-by: Jonathan Cameron

iio: st_sensors: Init trigger before irq request

2016-05-29T19:25:27+00:00

This fixes a possible race where an interrupt arrives before complete
initialization and crashes because iio_trigger_get_drvdata returns NULL.

Cc: Giuseppe Barba 
Cc: Denis Ciocca 
Signed-off-by: Crestez Dan Leonard 
Reviewed-by: Linus Walleij 
Signed-off-by: Jonathan Cameron