The end-of-conversion (EOC) GPIO line is better to grab using
a GPIO descriptor. We drop the pdata for this: clients using board
files can use machine descriptor tables to pass this GPIO from
static data.
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The device is always in a low-power state due to the hardware design. It
wakes up upon a conversion request and goes back into the low-power
state. The pm ops are added to disable the device completely and to free
the regulator. Disbaling the device completely should be not that
notable but freeing the regulator is important. Because if it is a shared
power-rail the regulator won't be disabled during suspend-to-ram/disk
and so all devices connected to that rail keeps on.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
commit f7072198f2 ("iio: imu: Fix inv_mpu6050 dependencies")
undid the explicit selection of I2C_MUX previously
done by the driver, because I2C_MUX implicitly depended
on HAS_IOMEM.
However commit 93d710a65e ("i2c: mux: fix up dependencies")
cleared up the situation properly and drivers that need
to select I2C_MUX can now do so again.
It makes a lot of sense for a driver to select the driver
infrastructure it needs so restore the natural order of
things.
Cc: Richard Weinberger <richard@nod.at>
Cc: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The channels specification assignment in chip info was simplified.
This patch makes supporting other devices by this driver easier.
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for parallax ping and laser ping sensors with just one pin
for trigger and echo signal.
This driver is based on srf04. In contrast to it it's necessary to
change direction of the pin and to request the irq just for the period
when the echo is rising and falling. Because this adds a lot of cases
there is this individual driver for handling this type of sensors.
Add a new configuration variable CONFIG_PING to Kconfig and Makefile.
Julia reported an issue with failing to unlock a mutex in some error
paths.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There is no need to explicitly generate update event to update
timer master mode.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Previously, the code was using the of_read_property_bool() to check if
an external regulator was provided. However, this is redundant, as it's
more simple/direct to just ask the regulator is provided, via a
`devm_regulator_get_optional()` call.
Signed-off-by: Alexandru Tachici <alexandru.tachici@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We added a sysfs ABI for getting/setting the type of a thermocouple. This
driver supports chips that support specific fixed thermocouple types; we
cannot set it, but still we can add this sysfs attribute in RO mode to
read-back the thermocouple type.
This driver supports actually several chips:
- max6675
- max31855[k/j/n/s/t/e/r]asa family
Max6675 supports only K-type thermocouples, so we can just report that.
Each chip in max31855 family supports just one specific thermocouple type
(in the obvious way: i.e. max31855jasa supports J-type). This driver did
accept a generic SPI ID and OF compatible "max31855" which does not give
any clue about which chip is really involved (and unfortunately it seems
we have no way to detect it).
This patch introduces a new set of, more specific, SPI IDs and OF
compatible strings to better match the chip type.
The old, generic, "max31855" binding is kept for compatibility reasons, but
this patch aims to deprecate it, so, should we hit it, a warning is spit.
In such case the reported thermocouple type in sysfs is '?', because we
have no way to know.
Regarding the implementation: the thermocouple type information is stored
in the driver private data and I've kept only two maxim_thermocouple_chip
types in order to avoid a lot of duplications (seven chip types with just
a different thermocouple type).
RFT because I have no real HW to test this.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The sensor support various thermocouple types (e.g. J, K, N, ...). The
driver allows to configure this parameter using a DT property.
This is useful when i.e. the thermocouple is physically tied to the sensor
and it is usually not removed, or when it is at least known in advance
which sensor will be connected to the circuit.
However, if the user can randomly connect any kind of thermocouples (i.e.
the device exposes a connector, and the user is free to connect its own
sensors), it would be more appropriate to provide a mechanism to
dynamically switch from one thermocouple type to another. This can be i.e.
handled in userspace by a GUI, a configuration file or a program that
detects the thermocouple type by reading a GPIO, or a eeprom on the probe,
or whatever.
This patch adds a IIO attribute that can be used to override, at run-time,
the DT-provided setting (which serves as default).
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We have a couple of thermocouple IIO drivers, supporting several chips.
Some of them support only one specific thermocouple type (e.g. "K", "J"),
one of them can be configured to work with several different thermocouple
types.
In certain applications thermocouples could be externally connected to the
chip by the user.
This patch introduces a new IIO standard attribute to report the supported
thermocouple type and, where applicable, to allow it to be dynamically set
using sysfs.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This patch introduces IIO_VAL_CHAR type for standard IIO attributes to
allow for attributes that needs to be represented by character rather
than a number. This is preparatory for introducing a new attribute whose
purpose is to describe thermocouple type, that can be i.e. "J", "K", etc..
The char-type value is stored in the first "value" integer that is passed
to the .[read/write]_raw() callbacks.
Note that in order to make it possible for the IIO core to correctly parse
this type (actually, to avoid integer parsing), it became mandatory for
any driver that wish to use IIO_VAL_CHAR on a writable attribute to
implement .write_raw_get_fmt().
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This sensor can perform samples averaging in hardware, but currently the
driver leaves this setting alone (default is no averaging).
This patch binds this HW setting to the "oversampling_ratio" IIO attribute
and allows the user to set the averaging as desired (the HW supports
averaging of 2, 5, 8 or 16 samples; in-between values are rounded up).
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This sensor has an embedded notch filter for reducing interferences caused
by the power mains. This filter can be tuned to reject either 50Hz or 60Hz
(and harmonics).
Currently the said setting is left alone (the sensor defaults to 60Hz).
This patch introduces a IIO attribute that allows the user to set the said
filter to the desired frequency.
NOTE: this has been intentionally not tied to any DT property to allow
the configuration of this setting from userspace, e.g. with a GUI or by
reading a configuration file, or maybe reading a GPIO tied to a physical
switch or accessing some device that can autodetect the line frequency.
Cc: Hartmut Knaack <knaack.h@gmx.de>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Colin Ian King <colin.king@canonical.com>
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Cc: Matt Weber <matthew.weber@rockwellcollins.com>
Cc: Matt Ranostay <matt.ranostay@konsulko.com>
Cc: Chuhong Yuan <hslester96@gmail.com>
Cc: Daniel Gomez <dagmcr@gmail.com>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change uses the ADIS library's state_lock to protect the state of the
`max_speed_hz` change that is done during the set of the sampling
frequency.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
It's the only operation that does 2 operations (a read & a write), so the
unlocked functions can be used under a single state lock.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This replaces indio_dev's mlock with the state lock/mutex from the ADIS
library.
The __adis16136_get_freq() function has been prefixed to mark it as
unlocked. The adis16136_{set,get}_filter() functions now hold the state
lock for all the ops that they do.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change removes the use of indio_dev's mlock in favor using the state
lock from the ADIS library.
The set_freq() & get_freq() hooks are unlocked, so they require specific
locking. That is because in some cases the get_freq() hook is used in
combination with adis16400_set_filter().
In cases where only one read/write is done, the functions that hold the
state lock are used.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The single conversion function does a series of reads + writes. This change
extends the use of the state_lock for the entire set of operations.
Previously, indio_dev's mlock was used. This change also removes the use of
this lock.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The initial startup routine is called by some ADIS drivers during probe,
and before registering with IIO. Normally, userspace should not be able to
do any access to the device (as there shouldn't be any available).
This change extends the state lock to the entire initial-startup routine.
Behaviourally nothing should change, but this should make the library
function a bit more robust.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The reset routine may also be important to be protected by the state-lock
and grouped with other operations, so create an unlocked version, so that
this can be done.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This one also gets re-used in certain operations, so it makes sense to
have an unlocked version of this to group it with other
reads/writes/operations to have a single lock for the whole state change.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The adis_enable_irq() does a read & a write. This change keeps a lock for
the duration of both operations vs for each op.
The change is also needed in adis16480, since that has it's own
implementation for adis_enable_irq().
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This will allow more flexible control to group reads & writes into a single
lock (particularly the state_lock).
The end-goal is to remove the indio_dev->mlock usage, and the simplest fix
would have been to just add another lock, which would not be a good idea on
the long-run.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The lock can be extended a bit to protect other elements that are not
particular to just TX/RX. Another idea would have been to just add a new
`state_lock`, but that would mean 2 locks which would be redundant, and
probably cause more potential for dead-locks.
What will be done in the next patches, will be to add some unlocked
versions for read/write_reg functions.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The relations between enum values and array indices values are currently
not enforced by the code, which makes them fragile w.r.t. future
changes.
Fix this by:
1. Using designated array initializers, to make sure array indices and
enums values match,
2. Linking max9611_csa_gain enum values to the corresponding
max9611_conf_ids enum values, as the latter is cast to the former
in max9611_read_csa_voltage().
No change in generated code.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support for driving MPU9150 magnetometer (AK8975) from mpu.
Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
MPU9150 is i2c only.
Update Kconfig to delete in description chips that are i2c or
spi only.
Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The scale can now be obtained with the "in_voltage_scale" file.
By default, the scale returned corresponds to the internal VREF of 2.5V.
It is possible to use an external VREF (through the REFIN/REFOUT pin of
the chip), by passing a regulator to the driver. The scale will then be
calculated according to the voltage reported by the regulator.
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
AD7091R5 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.
This driver will also support AD7091R2/4/8 in the future.
Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
Signed-off-by: Paul Cercueil <paul.cercueil@analog.com>
Co-developed-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Beniamin Bia <beniamin.bia@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
New device support
* ad5446
- Support the ad5600 DAC (id only needed).
* ad7292 ADC DAC etc
- New driver plus dt-bindings.
* veml6030 ambient light sensor
- New driver plus dt-bindings and sysfs docs.
Features
* mpu6050
- Explicit VDD control.
* stm32-adc
- Allow limiting of max clock frequency from devicetree to ensure it's
suitable for external circuitry.
yaml binding conversions
* ltc1660
* mcp3911
Fixes
* adis16480
- Fix wrong scale factors.
- Fix debugfs reg access by providing the callback.
* cros_ec_baro
- Fixing missing mask entry to make available sample frequencies visible
in sysfs.
* st_lsm6dsx
- Explicitly handle different ODR table sizes.
- Handle restrictions between slave ODR and accel ODR when
both are enabled.
- Allow ODR to be expressed more accurately by using miliHz.
* tools
- Fix an issue with parallel builds.
Cleanups and warning fixes
* adis16136, adis16400, adis16460, adis-lib
- Change some checks on return values to be for 0 rather than strictly
negative. Avoids some fiddly issues with the compiler concluding some
variables are initialized due to a mixture of error checks.
- Assign values only on success of 'read' operations - avoiding any
chance the compiler will falsly suggest they might be used uninitialized.
- Whitespace and simlar cleanups.
* aspeed adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* bcm-iproc-adc
- Stray semicolon removal.
* cc10001
- devm_platfom_ioremap_resource to reduce boilerplate.
* dln2-adc
- Reorganise the buffered mode setup and tear down. Part of moving towards
being able to refactor this area of the IIO core.
* hdc100x
- Reorganise the buffered mode setup and tear down.
* ingenic-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* lpc18xx-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* lpc18xx-dac
- devm_platfom_ioremap_resource to reduce boilerplate.
* mt6577
- devm_platfom_ioremap_resource to reduce boilerplate.
* npcm
- devm_platfom_ioremap_resource to reduce boilerplate.
* rcar-gyroadc
- devm_platfom_ioremap_resource to reduce boilerplate.
* spear-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* vf610-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* vf610-dac
- devm_platfom_ioremap_resource to reduce boilerplate.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAl3JsAoRHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0Foiw0w//Qpe9IxW4kdiMZB0vMr0mz74Aa6niS1Rm
c/vMEv7x/0cHjNBJWZiI4VQqScadVMMk2nD/KHAMt+9ZgZg+/r9d7PkVsrEIydZw
XBFf8qwFYoxL6jAgWinuCWuWAE3o9aKVqqGj/aosloUwzZDBXUpmCSnRpBFOhEyp
hbNNYZJo4Sbrg/xOYqyIaGJFTes0u+n8OuiS53dLN71lGW6BbGyJQtPzb/7rkOV/
z7zL0nbIfXszRrFQc17eBlblZvWl3QtHY08aiem8gcTkQbzTOTVWgLxyg+aZwBB2
XkCeeI21gLjVh2rxAcqBTs7OWObyGUjVES0+fAGBqIGEslq9nruMPrVrlTqkUHxJ
+vMPPA2VqvAqLI6cBz8oG9HsO/TUTQaRV3tHMF5WnoX9mDEzu9A8V4Cd7pg15lc1
aEvDXq5UU+aocKOofvyZJ8LqBi0ZmxJpohMGHHyDPmdtlL/HuWWsn9FyzsSgdBuc
EiGH+GKlUnG4mNOibr2L+TOBZwyelL+wGu40Xld3+KTyHyaysvQ2puP6wHTVf1da
ME0e6sFDPk4k+JTmsT9vYljgEfW3IMuTzI0BePlsfsx3/SbMZqdYLkijIHM1mpyE
yhaP/00u4aDFOlE1Ct0iwakUJ4Myxw0UeOz6deNKdTHcOExy28c8AIG6dqZhAJ9S
ohWETBDIDzI=
=ckQz
-----END PGP SIGNATURE-----
Merge tag 'iio-for-5.5c' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Third set of IIO new device support cleanups and fixes for the 5.5 cycle.
New device support
* ad5446
- Support the ad5600 DAC (id only needed).
* ad7292 ADC DAC etc
- New driver plus dt-bindings.
* veml6030 ambient light sensor
- New driver plus dt-bindings and sysfs docs.
Features
* mpu6050
- Explicit VDD control.
* stm32-adc
- Allow limiting of max clock frequency from devicetree to ensure it's
suitable for external circuitry.
yaml binding conversions
* ltc1660
* mcp3911
Fixes
* adis16480
- Fix wrong scale factors.
- Fix debugfs reg access by providing the callback.
* cros_ec_baro
- Fixing missing mask entry to make available sample frequencies visible
in sysfs.
* st_lsm6dsx
- Explicitly handle different ODR table sizes.
- Handle restrictions between slave ODR and accel ODR when
both are enabled.
- Allow ODR to be expressed more accurately by using miliHz.
* tools
- Fix an issue with parallel builds.
Cleanups and warning fixes
* adis16136, adis16400, adis16460, adis-lib
- Change some checks on return values to be for 0 rather than strictly
negative. Avoids some fiddly issues with the compiler concluding some
variables are initialized due to a mixture of error checks.
- Assign values only on success of 'read' operations - avoiding any
chance the compiler will falsly suggest they might be used uninitialized.
- Whitespace and simlar cleanups.
* aspeed adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* bcm-iproc-adc
- Stray semicolon removal.
* cc10001
- devm_platfom_ioremap_resource to reduce boilerplate.
* dln2-adc
- Reorganise the buffered mode setup and tear down. Part of moving towards
being able to refactor this area of the IIO core.
* hdc100x
- Reorganise the buffered mode setup and tear down.
* ingenic-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* lpc18xx-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* lpc18xx-dac
- devm_platfom_ioremap_resource to reduce boilerplate.
* mt6577
- devm_platfom_ioremap_resource to reduce boilerplate.
* npcm
- devm_platfom_ioremap_resource to reduce boilerplate.
* rcar-gyroadc
- devm_platfom_ioremap_resource to reduce boilerplate.
* spear-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* vf610-adc
- devm_platfom_ioremap_resource to reduce boilerplate.
* vf610-dac
- devm_platfom_ioremap_resource to reduce boilerplate.
* tag 'iio-for-5.5c' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (43 commits)
iio: adis16480: Add debugfs_reg_access entry
iio: adis16480: Fix scales factors
tools: iio: Correctly add make dependency for iio_utils
iio: adc: Add driver support for AD7292
dt-bindings: iio: adc: Add dt-schema for AD7292
dt-bindings: iio: adc: Migrate MCP3911 documentation to yaml
iio: imu: mpu6050: Add support for vdd-supply regulator
dt-bindings: iio: imu: mpu6050: add vdd-supply
iio: cros_ec_baro: set info_mask_shared_by_all_available field
iio: dac: ad5446: Add support for new AD5600 DAC
dt-bindings: iio: dac: Migrate LTC1660 documentation to yaml
iio: documentation: light: Add veml6030 sysfs documentation
dt-bindings: iio: light: add veml6030 ALS bindings
iio: light: add driver for veml6030 ambient light sensor
iio: imu: st_lsm6dsx: express odr in mHZ
iio: imu: st_lsm6dsx: fix ODR check in st_lsm6dsx_write_raw
iio: imu: st_lsm6dsx: explicitly define odr table size
iio: adc: stm32: allow to tune analog clock
dt-bindings: iio: stm32-adc: add max clock rate property
iio: dac: vf610: Use devm_platform_ioremap_resource
...
The driver is defining debugfs entries by calling
`adis16480_debugfs_init()`. However, those entries are attached to the
iio_dev debugfs entry which won't exist if no debugfs_reg_access
callback is provided.
Fixes: 2f3abe6cbb ("iio:imu: Add support for the ADIS16480 and similar IMUs")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This patch fixes the scales for the gyroscope, accelerometer and
barometer. The pressure scale was just wrong. For the others, the scale
factors were not taking into account that a 32bit word is being read
from the device.
Fixes: 7abad1063d ("iio: adis16480: Fix scale factors")
Fixes: 82e7a1b250 ("iio: imu: adis16480: Add support for ADIS1649x family of devices")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The AD7292 is a 10-bit monitor and control system with ADC, DACs,
temperature sensor, and GPIOs.
Configure AD7292 devices in direct access mode, enabling single-ended
ADC readings.
Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/ad7292.pdf
Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
MPU6050 has two power supply pins: VDD and VLOGIC, but the
mpu6050 driver only supports enabling one of them at the moment.
In some cases, they may need to be enabled separately.
Add an additional "vdd-supply" that stays enabled for as long as
the driver is loaded. We cannot turn off the VDD regulator during
suspend as this would cause register settings (FSR, sampling rate, ...)
to be lost.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Field was already set for light/proximity and
accelerometer/gyroscope/magnetometer sensors.
Fixes: ae7b02ad2f ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The AD5600 is a single channel, 16-bit resolution, voltage output digital
to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is
part of the AD5541 family of DACs.
The ad5446 IIO driver implements support for some of these DACs (in the
AD5441 family), so the change is a simple entry in this driver.
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
veml6030 is an ambient light sensor from Vishay semiconductors.
It has 16-bit resolution, supports both ambient light measurement
and white channel which is more responsive to wider wavelength
spectrum. It has flexible power saving, integration time and
gain options. Communication with host is over I2C.
Signed-off-by: Rishi Gupta <gupt21@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Express available frequencies in mHZ in order to support even
rational ODRs. This patch is need to fix an Android CTS failure
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Since st_lsm6dsx i2c master controller relies on accel device as trigger
and slave devices can run at different ODRs we must select an accel_odr >=
slave_odr. Report real accel ODR in st_lsm6dsx_check_odr() in order to
properly set sensor frequency in st_lsm6dsx_write_raw and avoid to
report unsupported frequency
Fixes: 6ffb55e500 ("iio: imu: st_lsm6dsx: introduce ST_LSM6DSX_ID_EXT sensor ids")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Introduce odr_len in st_lsm6dsx_odr_table_entry data structure in order
to explicitly define odr table size and support devices with different
odr table map
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add new optional dt property to tune analog clock prescaler.
Driver looks for optional "st,max-clk-rate-hz", then computes
best approximation below that rate, using ADC internal prescaler.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reduce local boilerplate.
Suggested by coccinelle
CHECK drivers/iio/dac/vf610_dac.c
drivers/iio/dac/vf610_dac.c:189:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Sanchayan Maity <maitysanchayan@gmail.com>
Reduce boilerplate.
Suggested by coccinelle
CHECK drivers/iio/dac/lpc18xx_dac.c
drivers/iio/dac/lpc18xx_dac.c:121:1-10: WARNING: Use devm_platform_ioremap_resource for dac -> base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
CC: Joachim Eastwood <manabian@gmail.com>
Reduces boilerplate.
Suggested by coccinelle
CHECK drivers/iio/adc/vf610_adc.c
drivers/iio/adc/vf610_adc.c:819:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Fugang Duan <b38611@freescale.com>
Avoids local boilerplate doing the same thing.
Suggested by coccinelle
CHECK drivers/iio/adc/spear_adc.c
drivers/iio/adc/spear_adc.c:283:1-22: WARNING: Use devm_platform_ioremap_resource for st -> adc_base_spear6xx
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Avoids some local boilerplate.
Suggested by coccinelle.
CHECK drivers/iio/adc/rcar-gyroadc.c
drivers/iio/adc/rcar-gyroadc.c:495:1-11: WARNING: Use devm_platform_ioremap_resource for priv -> regs
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Marek Vasut <marek.vasut+renesas@gmail.com>
Reduces local boilerplate code.
Suggested by coccinelle via coccicheck.
CHECK drivers/iio/adc/npcm_adc.c
drivers/iio/adc/npcm_adc.c:200:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Tomer Maimon <tmaimon77@gmail.com>
Avoid local boilerplate.
Identified by coccinelle
CHECK drivers/iio/adc/lpc18xx_adc.c
drivers/iio/adc/lpc18xx_adc.c:137:1-10: WARNING: Use devm_platform_ioremap_resource for adc -> base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Joachim Eastwood <manabian@gmail.com>
Replaces local boilerplate. Identified by coccinelle.
CHECK drivers/iio/adc/ingenic-adc.c
drivers/iio/adc/ingenic-adc.c:449:1-10: WARNING: Use devm_platform_ioremap_resource for adc -> base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Artur Rojek <contact@artur-rojek.eu>
Reduces local boilerplate.
Found by coccinelle:
drivers/iio/adc/cc10001_adc.c:344:1-18: WARNING: Use devm_platform_ioremap_resource for adc_dev -> reg_base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Naidu Tellapati <naidu.tellapati@imgtec.com>
Reduces boilerplate. Identified by coccinelle
CHECK drivers/iio/adc/mt6577_auxadc.c
drivers/iio/adc/mt6577_auxadc.c:257:1-18: WARNING: Use devm_platform_ioremap_resource for adc_dev -> reg_base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Zhiyong Tao <zhiyong.tao@mediatek.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reduces boilerplate.
Identified by: Coccinelle / coccicheck
CHECK drivers/iio/adc/aspeed_adc.c
drivers/iio/adc/aspeed_adc.c:189:1-11: WARNING: Use devm_platform_ioremap_resource for data -> base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Rick Altherr <raltherr@google.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
This was also caught by the `-Wmaybe-uninitialized` warning, which
(ironically as-is) it makes quite a lot of sense to do for this.
The code that actually calls this function will fail to copy on
the uninitialized value. Hence, patch does not need to go into stable.
Fixes: 78026a6fde ("iio:imu:adis: Add debugfs register access support")
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This was found only after the whole thing with the inline functions, but
the compiler actually found something. The value of the `bias` (in
adis16480_get_calibbias()) should only be set if the read operation was
successful.
No actual known problem occurs as users of this function all
ultimately check the return value. Hence probably not stable material.
Fixes: 2f3abe6cbb ("iio:imu: Add support for the ADIS16480 and similar IMUs")
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is a typical checkpatch warning. The change just renames the type of
the `freq` var to `unsigned int`.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This is just a minor indentation/alignment fix for the default case of a
switch statement.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADIS library functions return zero on success, and negative values for
error. Positive values aren't returned, but we only care about the success
value (which is zero).
This change is mostly needed so that the compiler won't make any inferences
about some about values being potentially un-initialized. This only
triggers after making some functions inline, because the compiler can
better follow return paths.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADIS library functions return zero on success, and negative values for
error. Positive values aren't returned, but we only care about the success
value (which is zero).
This change is mostly needed so that the compiler won't make any inferences
about some about values being potentially un-initialized. This only
triggers after making some functions inline, because the compiler can
better follow return paths.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADIS library functions return zero on success, and negative values for
error. Positive values aren't returned, but we only care about the success
value (which is zero).
This change is mostly needed so that the compiler won't make any inferences
about some about values being potentially un-initialized. This only
triggers after making some functions inline, because the compiler can
better follow return paths.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADIS library functions return zero on success, and negative values for
error. Positive values aren't returned, but we only care about the success
value (which is zero).
This change is mostly needed so that the compiler won't make any inferences
about some about values being potentially un-initialized. This only
triggers after making some functions inline, because the compiler can
better follow return paths.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADIS library functions return zero on success, and negative values for
error. Positive values aren't returned, but we only care about the success
value (which is zero).
This change is mostly needed so that the compiler won't make any inferences
about some about values being potentially un-initialized. This only
triggers after making some functions inline, because the compiler can
better follow return paths.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_triggered_buffer_postenable() hook should be called first to
attach the poll function and the iio_triggered_buffer_predisable() hook
should be called last in the predisable hook.
This change updates the driver to attach/detach the poll func in the
correct order.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_triggered_buffer_postenable() hook should be called first to
attach the poll function. The iio_triggered_buffer_predisable() hook is
called last (as is it should).
This change moves iio_triggered_buffer_postenable() to be called first. It
adds iio_triggered_buffer_predisable() on the error paths of the postenable
hook.
For the predisable hook, some code-paths have been changed to make sure
that the iio_triggered_buffer_predisable() hook gets called in case there
is an error before it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support to STM LSM6DSRX 6-axis (acc + gyro) Mems sensor
https://www.st.com/resource/en/datasheet/lsm6dsrx.pdf
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
There maybe a race when using dmaengine_terminate_all(). The predisable
routine may call iio_triggered_buffer_predisable() prior to a pending DMA
callback.
Adopt dmaengine_terminate_sync() to ensure there's no pending DMA request
before calling iio_triggered_buffer_predisable().
Fixes: 2763ea0585 ("iio: adc: stm32: add optional dma support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
None of the ST sensor drivers use any symbols from
<linux/gpio.h>, just drop the include from all of them.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Set gain in hx711_reset() to its default value after a reset cycle. This
omits one precautionary read cycle, because the read is performed in
hx711_set_gain_for_channel() anyway if gain has changed.
Check for DOUT low and if its high wait some time if it goes down
instead of doing a blind reset cycle when DOUT is not down.
This is a performance optimization which allows to query the sensor with
a higher frequency.
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix the following warnings when documentation is built:
drivers/iio/adc/stm32-adc-core.c:62: warning: cannot understand function
prototype: 'struct stm32_adc_common_regs '
drivers/iio/adc/stm32-adc-core.c:78: warning: cannot understand function
prototype: 'struct stm32_adc_priv_cfg '
drivers/iio/adc/stm32-adc-core.c:123: warning: Function parameter or
member 'pdev' not described in 'stm32f4_adc_clk_sel'
drivers/iio/adc/stm32-adc.c:219: warning: cannot understand function
prototype: 'struct stm32_adc_regs '
drivers/iio/adc/stm32-adc.c:237: warning: cannot understand function
prototype: 'struct stm32_adc_regspec '
drivers/iio/adc/stm32-adc.c:264: warning: cannot understand function
prototype: 'struct stm32_adc_cfg '
drivers/iio/adc/stm32-adc.c:323: warning: Function parameter or member
'difsel' not described in 'N'
drivers/iio/adc/stm32-adc.c:323: warning: Function parameter or member
'pcsel' not described in 'stm32_adc'
drivers/iio/adc/stm32-adc.c:371: warning: cannot understand function
prototype: 'const struct stm32_adc_regs stm32f4_sq[STM32_ADC_MAX_SQ + 1]
drivers/iio/adc/stm32-adc.c:417: warning: cannot understand function
prototype: 'const struct stm32_adc_regs stm32f4_smp_bits[] = '
drivers/iio/adc/stm32-adc.c:508: warning: cannot understand function
prototype: 'const struct stm32_adc_regs stm32h7_smp_bits[] = '
drivers/iio/adc/stm32-adc.c:1112: warning: Function parameter or member
'indio_dev' not described in 'stm32_adc_get_trig_extsel'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'indio_dev' not described in 'stm32_adc_debugfs_reg_access'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'reg' not described in 'stm32_adc_debugfs_reg_access'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'writeval' not described in 'stm32_adc_debugfs_reg_access'
drivers/iio/adc/stm32-adc.c:1420: warning: Function parameter or member
'readval' not described in 'stm32_adc_debugfs_reg_access'
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The iio_triggered_buffer_{predisable,postenable} functions attach/detach
the poll functions.
The iio_triggered_buffer_postenable() should be called before (to attach
the poll func) and then the
The iio_triggered_buffer_predisable() function is hooked directly without
anything, which is probably fine, as the postenable() version seems to also
do some reset/wake-up of the device.
This will mean it will be easier when removing it; i.e. it just gets
removed.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Some chips have a fifo overflow bit issue where the bit is always
set. The result is that every data is dropped.
Change fifo overflow management by checking fifo count against
a maximum value.
Add fifo size in chip hardware set of values.
Fixes: f5057e7b2d ("iio: imu: inv_mpu6050: better fifo overflow handling")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Suggestion from coccinelle / coccicheck
CHECK drivers/iio/adc/twl4030-madc.c
drivers/iio/adc/twl4030-madc.c:524:6-15: WARNING: Comparison of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:655:1-43: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:659:2-44: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:664:1-43: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:498:2-34: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:510:2-19: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:511:2-11: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:531:2-19: WARNING: Assignment of 0/1 to bool variable
drivers/iio/adc/twl4030-madc.c:532:2-11: WARNING: Assignment of 0/1 to bool variable
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
The LTC2983 is a Multi-Sensor High Accuracy Digital Temperature
Measurement System. It measures a wide variety of temperature sensors and
digitally outputs the result, in °C or °F, with 0.1°C accuracy and
0.001°C resolution. It can measure the temperature of all standard
thermocouples (type B,E,J,K,N,S,R,T), standard 2-,3-,4-wire RTDs,
thermistors and diodes.
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
We can drop some duplicate code if we use devm_action for disabling
regulators and pm and the managed variant of iio_device_register().
This allows us to completely remove all remove() callbacks from both
i2c and spi code.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The vddd and vdda supplies are always operated on together. We can
shrink the code a bit by using the bulk regulator helpers.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
FXOS8700CQ is a small, low-power, 3-axis linear accelerometer and 3-axis
magnetometer combined into a single package. The device features a
selectable I2C or point-to-point SPI serial interface with 14-bit
accelerometer and 16-bit magnetometer ADC resolution along with
smart-embedded functions.
FXOS8700CQ has dynamically selectable accelerationfull-scale ranges of
±2 g/±4 g/±8 g and a fixed magnetic measurement range of ±1200 μT.
Output data rates (ODR) from 1.563 Hz to 800 Hz are selectable by the user
for each sensor. Interleaved magnetic and acceleration data is available
at ODR rates of up to 400 Hz. FXOS8700CQ is available in a plastic QFN
package and it is guaranteed to operate over the extended temperature
range of –40 °C to +85 °C.
TODO: Trigger and IRQ configuration support
Datasheet:
http://cache.freescale.com/files/sensors/doc/data_sheet/FXOS8700CQ.pdf
Signed-off-by: Robert Jones <rjones@gateworks.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reduces local boilerplate.
Suggested by coccinelle.
CHECK drivers/iio/adc/xilinx-xadc-core.c
drivers/iio/adc/xilinx-xadc-core.c:1184:1-11: WARNING: Use devm_platform_ioremap_resource for xadc -> base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Manish Narani <manish.narani@xilinx.com>
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com>
Coccinelle noticed:
CHECK drivers/iio/adc/cpcap-adc.c
drivers/iio/adc/cpcap-adc.c:1009:9-34: ERROR: Threaded IRQ with no primary handler requested without IRQF_ONESHOT
As far as I can see this is a simple case of it should be specified
but isn't.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Avoid local boilerplate.
Suggested by coccinelle via coccicheck.
CHECK drivers/iio/adc/meson_saradc.c
drivers/iio/adc/meson_saradc.c:1218:1-5: WARNING: Use devm_platform_ioremap_resource for base
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reduce local boilerplate.
Identified by coccinelle
drivers/iio/adc/exynos_adc.c:792:1-11: WARNING: Use devm_platform_ioremap_resource for info -> regs
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Sparse identified the following
CHECK drivers/iio/proximity/pulsedlight-lidar-lite-v2.c
drivers/iio/proximity/pulsedlight-lidar-lite-v2.c:144:24: warning: cast to restricted __be16
drivers/iio/proximity/pulsedlight-lidar-lite-v2.c:144:24: warning: cast to restricted __be16
drivers/iio/proximity/pulsedlight-lidar-lite-v2.c:144:24: warning: cast to restricted __be16
drivers/iio/proximity/pulsedlight-lidar-lite-v2.c:144:24: warning: cast to restricted __be16
This cleans up by adding a local variable to hold the value whilst
it is __be16 before applying endian converstion into eventual destination.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
There is a somewhat interesting mixture of be16 and le16 going on in
this one function. Changes here formalize that a little more.
CHECK drivers/iio/pressure/bmp280-core.c
drivers/iio/pressure/bmp280-core.c:215:35: warning: cast to restricted __le16
drivers/iio/pressure/bmp280-core.c:229:37: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:229:37: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:229:37: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:229:37: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:230:36: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:230:36: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:230:36: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:230:36: warning: cast to restricted __be16
drivers/iio/pressure/bmp280-core.c:237:37: warning: cast to restricted __le16
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
This clearly has no actual affect but it does show sparse and similar
static analysers that we are doing this intentionally.
CHECK drivers/iio/gyro/mpu3050-core.c
drivers/iio/gyro/mpu3050-core.c:546:48: warning: incorrect type in assignment (different base types)
drivers/iio/gyro/mpu3050-core.c:546:48: expected restricted __be16 <noident>
drivers/iio/gyro/mpu3050-core.c:546:48: got int
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
When breaking up a constant to write to two 8 bit registers
it isn't obvious to sparse that it was intentional.
CHECK drivers/iio/chemical/sps30.c
drivers/iio/chemical/sps30.c:120:30: warning: cast truncates bits from constant value (8004 becomes 4)
So in the interests of minimising noisy warnings, let us add
a mask.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Tomasz Duszynski <tduszyns@gmail.com>
Nothing stops data being of type __be16, which fixes the warning:
CHECK drivers/iio/adc/stmpe-adc.c
drivers/iio/adc/stmpe-adc.c:202:29: warning: cast to restricted __be16
drivers/iio/adc/stmpe-adc.c:202:29: warning: cast to restricted __be16
drivers/iio/adc/stmpe-adc.c:202:29: warning: cast to restricted __be16
drivers/iio/adc/stmpe-adc.c:202:29: warning: cast to restricted __be16
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: <philippe.schenker@toradex.com>
Cleans up the sparse warning:
CHECK drivers/iio/adc/at91-sama5d2_adc.c
drivers/iio/adc/at91-sama5d2_adc.c:1486:31: warning: Using plain integer as NULL pointer
drivers/iio/adc/at91-sama5d2_adc.c:1509:31: warning: Using plain integer as NULL pointer
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Eugen Hristev <eugen.hristev@microchip.com>
This is a new driver for the ST-Ericsson AB8500 GPADC, which
replaces the old driver in drivers/mfd/ab8500-gpadc.c and
thus gets rid of another necessarily different custom driver
from the times before IIO existed.
The AB8500 GPADC can convert 10 different channels and these
are used for monitoring voltages in the U8500 chipset, some
are used for battery charging, some for temperature
monitoring.
As this is very core functionality that a lot of drivers
depend on and was formerly compiled in with the AB8500 core
driver, we deafault it to 'y' in Kconfig: it can be compiled
out but it is really not advisible: the platform can
for example overheat if we do.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Exposes the ADC device present on, at least, Intel Merrifield platform.
Based on work done by:
Yang Bin <bin.yang@intel.com>
Huiquan Zhong <huiquan.zhong@intel.com>
Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Pavan Kumar S <pavan.kumar.s@intel.com>
Though it has been heavily rewritten for upstream.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add support to STM LSM6DS0 6-axis (acc + gyro) Mems sensor
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix typos in gyro gain definitions for LSM9DS1 sensor
Fixes: 52f4b1f196 ("iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9ds1")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This change replaces indio_dev's mlock with the driver's own lock. The lock
is mostly needed to protect state when changing the `dac_cache` info.
The lock has been extended to `ad7303_read_raw()`, to make sure that the
cache is updated if an SPI-write is already in progress.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
On LSM6DSO/LSM6DSR/LSM6DSOX/ASM330LHH and ISH330DHCX
devices it is possible to trim the hardware timestamp
resolution through the FREQ_FINE[7:0] bits of the
INTERNAL_FREQ_FINE register, which contains the difference
in percentage of the effective ODR (and timestamp rate)
with respect to the typical value.
The formula for calculating the effective ODR reported
in the application notes has been linearized to the first
order to simplify the calculation (pls. see note on source
code).
This change may be useful in the outcome of CTS
tests regarding the SingleSensorTests and the
SensorTest#testSensorTimeStamps for high ODRs
Signed-off-by: Mario Tesi <mario.tesi@st.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
