| Age | Commit message (Collapse) | Author |
|---|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
iio_trigger_ops.owner
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of this is now done via macro magic when
the relevant register call is made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of this is now done via macro magic when
the relevant register call is made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent is now done via macro magic when
the relevant register call is made. The actual structure
element will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent is now done via macro magic when
the relevant register call is made. The actual structure
element will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of this is now done via macro magic when
the relevant register call is made. The actual structure
element will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent is now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Clearly this set jumps across multiple areas, but inherently it
can't be grouped like the other sets in this series so I've done
all the stuff in the common directory together.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
iio_trigger_ops.owner
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
The equivalent of both of these are now done via macro magic when
the relevant register calls are made. The actual structure
elements will shortly go away.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
There are a few cases where none of the callbacks are supplied and the
ops structure purely existed to provide the driver module.
Given that is done differently now, we don't need to have a trig_ops structure.
Allow for it not being there required a few additional sanity checks when
trying check if particular callbacks are set.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
This trig_ops.owner assignment occurs in all trigger drivers and
can be simply automated using a macro as has been done in many
other places in the kernel.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
Starting point in boiler plate reduction similar to that done for
many similar cases elsewhere in the kernel.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Second set of IIO new device support, features and cleanup for the 4.14 cycle.
New device support:
* ak8974
- support the AMI306.
* st_magnetometer
- add support for the LIS2MDL with bindings.
* rockchip-saradc
- add binding for rv1108 SoC (no driver change).
* srf08
- add srf02 (i2c only) and srf10 support.
* stm32-timer
- support for the STM32H7 to existing driver.
Features:
* tools
- move over to the tools buildsystem rather than hand rolling.
- add an install section to the build.
* ak8974
- use serial number to add device randomness.
- add AMI306 calibration data output.
* ccs811
- triggered buffer support.
* srf08
- add a device tree table as the old style i2c probing is going away,
- add triggered buffer support
* st32-adc
- add optional st,min-sample-time-nsecs binding to allow control of
sampling against analog circuitry.
* stm32-timer
- add output compare triggers.
* ti-ads1015
- add threshold event support.
* ti-ads7950
- Allow use on ACPI platforms including providing a default reference
voltage as there is no way to obtain this on ACPI currently.
Cleanup and fixes:
* ad7606
- fix an error return code in probe.
* ads1015
- fix incorrect data rate setting update when capture in progress,
- fix wrong scale information for the ADS1115,
- make conversions work when CONFIG_PM is not set,
- make sure we don't get a stale result after a runtime resume by
ensuring we wait long enough,
- avoid returning a false error form the buffer setup callbacks,
- add enough wait time to get the correct conversion,
- remove an unnecessary config register update,
- add a helper to set conversion mode reducing repeated boilerplate,
- use devm_iio_triggered_buffer_setup to simplify error and remove
paths,
- use iio_device_claim_direct_mode instead of opencoding the same.
* ak8974
- mark the INT_CLEAR register as precious to prevent debugfs access.
* apds9300
- constify the i2c_device_id.
* at91-sama5 adc
- add missing Kconfig dependency.
* bma180 accel
- constify the i2c_device_id.
* rockchip_saradc
- explicitly request exclusive reset control as part of the reset rework
on going throughout the kernel.
* st_accel
- fix drdy configuration for a load of accelerometers that only have
the int1 line. Fix is unimportant as presumably no deviec tree actually
used the non existent hardware line.
* st_pressure
- fix drdy configuration for LPS22HB and LPS25H by dropping int2 support
as they don't have this. Fix is unimportant as presumably no device tree
actually used the non existent hardware line.
* stm32-dac
- explicitly request exclusive reset control (part of reset being reworked).
* tsl2583
- constify the i2c_device_id.
* xadc
- coding style fixes.
|
|
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-iio@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.
No functional changes.
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ADS1015 device provides programmable comparator that can issue an
interrupt on the ALERT pin. This change adds the iio threshold event
support for that feature.
The ADS1015 device only have a single config register which contains an
input multiplexer selection, comparator settings, and etc. So only a
single event channel can be enabled at a time. Also enabling both buffer
and event are prohibited for simplicity.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
While the iio buffer for the ti-ads1015 driver is enabled, reading the
raw ADC channel data is restricted. We usually use the
iio_device_claim_direct_mode()/iio_device_release_direct_mode() pair for
that.
This change consequently reverses the locking order for the driver's
private lock and indio_dev->mlock which acquired by
iio_device_claim_direct_mode() internally. But it's safe because there is
no other dependency between these locks.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Use devm_iio_triggered_buffer_setup to simplify the error path in the
probe() and remove() function.
This changes the remove order, but the end result of remove function
actually does the reverse of probe.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
This adds a helper function to set conversion mode as there are a fair
number of users.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
The ti-ads1015 driver has eight iio voltage channels and each iio channel
can hold own scale 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 scale information immediately overwrites the current PGA
setting in the config register.
It is harmless because the correct PGA settings are reloaded just before
getting adc result anyway. But it is unnecessary register update and
should be removed.
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <daniel.baluta@gmail.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
ACPI enabled platforms do not have a mean of regulators. Instead we use
hard coded voltage value for reference pin. When value is 0 (default) we
fall back to request a regulator.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Use AMI306 calibration data for randomness and debugging.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <lorenzo.bianconi@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Fixes: 97865fe41322 (iio: st_sensors: verify interrupt event to status)
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <srinivas.pandruvada@linux.intel.com>
Tested-by: Bastien Nocera <hadess@hadess.net>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
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 <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
According to the datasheet, the range of the acceleration is [-10 g, + 10 g],
so the scale factor should be 10 instead of 5.
Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Reading INT_CLEAR has side effects - disallow reading it via debugfs.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Mix device-specific data into randomness pool.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
Add support for AMI306 magnetometer - very similar to AMI305.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
|
i2c_device_id are not supposed to change at runtime. All functions
working with i2c_device_id provided by <linux/i2c.h> work with
const i2c_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
