linux-stable.git/drivers/iio, branch v4.13.2

iio: adc: ti-ads1015: add adequate wait time to get correct conversion

2017-09-09T15:39:21+00:00

commit 4744d4e2afebf9644a439da9ca73d822fdd67bd9 upstream.

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
inserts a wait time before reading the conversion register if the
configuration is changed from a previous request.

Currently, the wait time is only the period required for a single
conversion that is calculated as the reciprocal of the sampling frequency.
However we also need to wait for the the previous conversion to complete.
Otherwise we probably get the conversion result for the previous
configuration when the sampling frequency is lower.

Cc: Daniel Baluta 
Signed-off-by: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ti-ads1015: don't return invalid value from buffer setup callbacks

2017-09-09T15:39:21+00:00

commit a6fe5e52d5ecfc98530034d6c9db73777cf41ede upstream.

pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
success, 1 if the device's runtime PM status was already requested status
or error code on failure.  So a positive return value doesn't indicate an
error condition.

However, any non-zero return values from buffer preenable and postdisable
callbacks are recognized as an error and this driver reuses the return
value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
these callbacks.  This change fixes the false error detections.

Cc: Daniel Baluta 
Signed-off-by: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ti-ads1015: avoid getting stale result after runtime resume

2017-09-09T15:39:20+00:00

commit 73e3e3fc50de50cfd68e945d85679c983ed31bd9 upstream.

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
doesn't insert a wait time before reading the conversion register if the
configuration is not changed from a previous request.

This assumption is broken if the device is runtime suspended and entered
a power-down state.  The forthcoming request causes reading a stale result
from the conversion register as the device is runtime resumed just before.

Fix it by adding a flag to detect that condition and insert a necessary
wait time.

Cc: Daniel Baluta 
Signed-off-by: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ti-ads1015: enable conversion when CONFIG_PM is not set

2017-09-09T15:39:20+00:00

commit e8245c68350104b6022b6783719e843d69ea7c43 upstream.

The ADS1015 device have two operating modes, continuous conversion mode
and single-shot mode.  This driver assumes that the continuous conversion
mode is selected by runtime resume callback when the ADC result is
requested.

If CONFIG_PM is disabled, the device is always in the default single-shot
mode and no one begins a single conversion.  So the conversion register
doesn't contain valid ADC result.  Fix it by changing the continuous mode
in probe function.

Cc: Daniel Baluta 
Signed-off-by: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ti-ads1015: fix scale information for ADS1115

2017-09-09T15:39:20+00:00

commit 8d0e8e795623bd6229cf48bb7777a1c456c370ed upstream.

The ti-ads1015 driver supports ADS1015 and ADS1115 devices.  The same
scale information is used for both devices in this driver, however they
have actually different values and the ADS1115's one is not correct.

These devices have the same full-scale input voltage range for each PGA
selection.  So instead of adding another hardcoded scale information,
compute a correct scale on demand from each device's resolution.

Cc: Daniel Baluta 
Signed-off-by: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ti-ads1015: fix incorrect data rate setting update

2017-09-09T15:39:20+00:00

commit 0d106b74c558e3000aa0e058b4725cacb70ce77a upstream.

The ti-ads1015 driver has eight iio voltage channels and each iio channel
can hold own sampling frequency information.

The ADS1015 device only have a single config register which contains an
input multiplexer selection, PGA and data rate settings.  So the driver
should load the correct settings when the input multiplexer selection is
changed.

However, regardless of which channlel is currently selected, changing any
iio channel's sampling frequency information immediately overwrites the
current data rate setting in the config register.

It breaks the current data rate setting if the different channel's sampling
frequency information is changed because the data rate setting is not
reloaded when the input multiplexer is switched.

This removes the unexpected config register update and correctly load the
data rate setting before getting adc result.

Cc: Daniel Baluta 
Signed-off-by: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: magnetometer: st_magn: remove ihl property for LSM303AGR

2017-08-20T14:21:49+00:00

Remove IRQ active low support for LSM303AGR since the sensor does not
support that capability for data-ready line

Fixes: a9fd053b56c6 (iio: st_sensors: support active-low interrupts)
Signed-off-by: Lorenzo Bianconi 
Reviewed-by: Linus Walleij 
Cc: 
Signed-off-by: Jonathan Cameron

iio: magnetometer: st_magn: fix status register address for LSM303AGR

2017-08-20T14:21:48+00:00

Fixes: 97865fe41322 (iio: st_sensors: verify interrupt event to status)
Signed-off-by: Lorenzo Bianconi 
Reviewed-by: Linus Walleij 
Cc: 
Signed-off-by: Jonathan Cameron

iio: hid-sensor-trigger: Fix the race with user space powering up sensors

2017-08-20T14:21:48+00:00

It has been reported for a while that with iio-sensor-proxy service the
rotation only works after one suspend/resume cycle. This required a wait
in the systemd unit file to avoid race. I found a Yoga 900 where I could
reproduce this.

The problem scenerio is:
- During sensor driver init, enable run time PM and also set a
  auto-suspend for 3 seconds.
	This result in one runtime resume. But there is a check to avoid
a powerup in this sequence, but rpm is active
- User space iio-sensor-proxy tries to power up the sensor. Since rpm is
  active it will simply return. But sensors were not actually
powered up in the prior sequence, so actaully the sensors will not work
- After 3 seconds the auto suspend kicks

If we add a wait in systemd service file to fire iio-sensor-proxy after
3 seconds, then now everything will work as the runtime resume will
actually powerup the sensor as this is a user request.

To avoid this:
- Remove the check to match user requested state, this will cause a
  brief powerup, but if the iio-sensor-proxy starts immediately it will
still work as the sensors are ON.
- Also move the autosuspend delay to place when user requested turn off
  of sensors, like after user finished raw read or buffer disable

Signed-off-by: Srinivas Pandruvada 
Tested-by: Bastien Nocera 
Cc: 
Signed-off-by: Jonathan Cameron

iio: trigger: stm32-timer: fix get trigger mode

2017-08-20T14:21:47+00:00

Fix reading trigger mode, when other bit-fields are set. SMCR register
value must be masked to read SMS (slave mode selection) only.

Fixes: 9eba381 ("iio: make stm32 trigger driver use
INDIO_HARDWARE_TRIGGERED mode")

Signed-off-by: Fabrice Gasnier 
Cc: 
Signed-off-by: Jonathan Cameron