summaryrefslogtreecommitdiffstats
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2019-12-29iio: imu: st_lsm6dsx: check if pull_up is located in primary pageLorenzo Bianconi2-5/+14
Check if the pull up register is located in the primary or in the secondary memory page. This is a preliminary patch to support i2c master controller on lsm6dsm devices Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: imu: st_lsm6dsx: check if master_enable is located in primary pageLorenzo Bianconi3-5/+14
Check if the master enable register is located in the primary or in the secondary memory page. This is a preliminary patch to support i2c master controller on lsm6dsm devices Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: imu: st_lsm6dsx: export max num of slave devices in ↵Lorenzo Bianconi3-2/+5
st_lsm6dsx_shub_settings Export max number of slave devices supported by the i2c master controller in st_lsm6dsx_shub_settings data structure. This is a preliminary patch to support i2c master controller on lsm6dsm sensors Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: light: remove unneeded semicolonChen Zhou1-1/+1
Fixes coccicheck warning: ./drivers/iio/light/lm3533-als.c:745:2-3: Unneeded semicolon Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: chemical: atlas-ph-sensor: rename atlas-ph-sensor to atlas-sensorMatt Ranostay2-6/+6
Since the orginal scope of the driver was to only support the pH product from Atlas it has evolved to other sensors. Rename the file, driver name, and regmap to atlas-sensor which reflects this, although keep CONFIG_ATLAS_PH_SENSOR to not cause regressions with current configurations. Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: st_sensors: Describe function parameters in kernel-docAndy Shevchenko1-0/+3
Kernel documentation script complains that some of the function parameters are not described: .../common/st_sensors/st_sensors_trigger.c:29: warning: Function parameter or member 'indio_dev' not described in 'st_sensors_new_samples_available' .../common/st_sensors/st_sensors_trigger.c:29: warning: Function parameter or member 'sdata' not described in 'st_sensors_new_samples_available' Describe function parameters where it's appropriate. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: pressure: st_press: Mark default_press_pdata with __maybe_unusedAndy Shevchenko1-1/+1
Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Mark default_press_pdata with __maybe_unused to calm a compiler down: In file included from drivers/iio/pressure/st_pressure_spi.c:18: drivers/iio/pressure/st_pressure.h:40:46: warning: ‘default_press_pdata’ defined but not used [-Wunused-const-variable=] 40 | static const struct st_sensors_platform_data default_press_pdata = { | ^~~~~~~~~~~~~~~~~~~ ... Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: accel: st_accel: Mark default_accel_pdata with __maybe_unusedAndy Shevchenko1-1/+1
Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Mark default_accel_pdata with __maybe_unused to calm a compiler down: In file included from drivers/iio/accel/st_accel_i2c.c:19: drivers/iio/accel/st_accel.h:67:46: warning: ‘default_accel_pdata’ defined but not used [-Wunused-const-variable=] 67 | static const struct st_sensors_platform_data default_accel_pdata = { | ^~~~~~~~~~~~~~~~~~~ ... Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: gyro: st_gyro: Mark gyro_pdata with __maybe_unusedAndy Shevchenko1-1/+1
Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Mark gyro_pdata with __maybe_unused to calm a compiler down: In file included from drivers/iio/gyro/st_gyro_i2c.c:18: drivers/iio/gyro/st_gyro.h:31:46: warning: ‘gyro_pdata’ defined but not used [-Wunused-const-variable=] 31 | static const struct st_sensors_platform_data gyro_pdata = { | ^~~~~~~~~~ ... Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: pressure: st_press: Drop unnecessary #else branch for ACPIAndy Shevchenko1-2/+0
ACPI_PTR() takes care of the argument in case of !CONFIG_ACPI. Remove unnecessary #else branch. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: accel: st_accel: Drop unnecessary #else branch for ACPIAndy Shevchenko1-2/+0
ACPI_PTR() takes care of the argument in case of !CONFIG_ACPI. Remove unnecessary #else branch. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: light: st_uvis25: Drop unneeded header inclusionAndy Shevchenko1-1/+0
There is no evidence that the driver supports or needs ACPI APIs. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: st_lsm6dsx: Make use of device propertiesAndy Shevchenko1-13/+13
Device property API allows to gather device resources from different sources, such as ACPI. Convert the drivers to unleash the power of device property API. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: st_lsm6dsx: Drop unneeded OF codeAndy Shevchenko2-4/+2
There is no need to have OF guard against ID table. Drop it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: st_lsm6dsx: Mark predefined constants with __maybe_unusedAndy Shevchenko1-2/+5
Since we put static variable to a header file it's copied to each module that includes the header. But not all of them are actually used it. Mark predefined constants with __maybe_unused to calm a compiler down: In file included from drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.c:17: .../st_lsm6dsx/st_lsm6dsx.h:399:28: warning: ‘st_lsm6dsx_available_scan_masks’ defined but not used [-Wunused-const-variable=] 399 | static const unsigned long st_lsm6dsx_available_scan_masks[] = {0x7, 0x0}; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .../st_lsm6dsx/st_lsm6dsx.h:392:36: warning: ‘st_lsm6dsx_event’ defined but not used [-Wunused-const-variable=] 392 | static const struct iio_event_spec st_lsm6dsx_event = { | ^~~~~~~~~~~~~~~~ ... Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928Daniel Junho1-4/+44
The ad7928 is software compatible with the ad7923. The ad7908 and ad7918 are the 8 and 10-bit versions of the ad7928. Signed-off-by: Daniel Junho <djunho@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: adc: ad7923: Add of_device_id tableDaniel Junho1-0/+10
Accomplish device tree compatibility to driver AD7923 by adding of_device_id table and making a subsequent call to MODULE_DEVICE_TABLE. Signed-off-by: Daniel Junho <djunho@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: adc: ad7923: Fix checkpatch warningDaniel Junho1-1/+1
Fix checkpatch warning: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' +static int ad7923_scan_direct(struct ad7923_state *st, unsigned ch) Signed-off-by: Daniel Junho <djunho@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: adc: ad7923: Remove the unused definesDaniel Junho1-4/+0
Removes the unused define AD7923_CHANNEL_x from the code. Signed-off-by: Daniel Junho <djunho@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: accel: bma400: basic regulator supportDan Robertson2-5/+38
Add support for the VDD and VDDIO regulators using the regulator framework. Signed-off-by: Dan Robertson <dan@dlrobertson.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-29iio: accel: Add driver for the BMA400Dan Robertson5-0/+997
Add a IIO driver for the Bosch BMA400 3-axes ultra-low power accelerometer. The driver supports reading from the acceleration and temperature registers. The driver also supports reading and configuring the output data rate, oversampling ratio, and scale. Signed-off-by: Dan Robertson <dan@dlrobertson.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: new driver to support Linear technology's ltc2496Uwe Kleine-König3-0/+119
This chip is similar to the LTC2497 ADC, it just uses SPI instead of I2C and so has a slightly different protocol. Only the actual hardware access is different. The spi protocol is different enough to not be able to map the differences via a regmap. Also generalize the entry in MAINTAINER to cover the newly introduced file. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: ltc2497: split protocol independent part in a separate moduleUwe Kleine-König4-209/+288
This allows to share most of this driver for the ltc2496 driver added in the next commit that is an SPI variant of the ltc2497. Initially I named the generic part ltc249x, but wild card names are frowned upon, so the generic part is called ltc2497-core even though it's not obvious that this is then to be reused for the ltc2496 driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: ti-ads1015: Make use of device property APIAndy Shevchenko1-31/+26
Make use of device property API in this driver so that both OF based system and ACPI based system can use this driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: ti-ads1015: Get rid of legacy platform dataAndy Shevchenko1-10/+8
Platform data is a legacy interface to supply device properties to the driver. In this case we even don't have in-kernel users for it. Just remove it for good. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: ti-ads7950: Fix a typo in an error messageChristophe JAILLET1-1/+1
Fix a typo: s/get get/to get/ Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: humidity: hts221: move register definitions to sensor structsLorenzo Bianconi1-13/+6
Move some register definitions to hts221_avg_list, hts221_avg_list and hts221_channels since they are used only there and simplify driver code Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: stm32-adc: Add check on overrun interruptFabrice Gasnier3-9/+69
Enable overrun interrupt on STM32 ADC. In case data register hasn't been read (by CPU or DMA), overrun condition is detected when there's new conversion data available. Stop grabbing data and log an error message. Use a threaded irq to avoid printing the error message from hard irq context. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: ssp_sensors: Convert to use GPIO descriptorsLinus Walleij3-31/+20
These three GPIO lines used by the Samsung sensor hub is pretty straight-forward to convert to use GPIO descriptors. Cc: Karol Wrona <k.wrona@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adc: Move AD7091R5 entry in a alphabetical order in MakefileBeniamin Bia2-8/+8
Ad7091R5 was added in a non alphabetical order after AD7124 in Makefile and KConfig. This patch fixes that and place Ad7091R5 before AD7124. Signed-off-by: Beniamin Bia <beniamin.bia@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: atlas-ph-sensor: Drop GPIO includeLinus Walleij1-1/+0
The driver includes <linux/gpio.h> yet fails to use symbols from any the header so drop the include. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: ad7266: Convert to use GPIO descriptorsLinus Walleij1-17/+12
The AD7266 have no in-tree users making use of the platform data mechanism to pass address GPIO lines when not using a fixed address, so we can easily convert this to use GPIO descriptors instead of the platform data integers currently passed. Lowercase the labels "ad0".."ad2" as this will make a better fit for platform descriptions like device tree that prefer lowercase names such as "ad0-gpios" rather than "AD0-gpios". Board files and other static users of this device can pass the same GPIO descriptors using machine descriptor tables if need be. Cc: Alison Schofield <amsfield22@gmail.com> Cc: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: ad5592r: Drop surplus GPIO headerLinus Walleij1-1/+0
This driver uses all the modern GPIO APIs from <linux/gpio/driver.h> and <linux/gpio/consumer.h> so just drop the unused legacy header <linux/gpio.h>. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: adf4350: Convert to use GPIO descriptorLinus Walleij1-22/+8
The lock detect 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: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: itg3200: Drop GPIO includeLinus Walleij1-1/+0
The driver include <linux/gpio.h> yet does not use any of the symbols from the header, so drop the include. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: apds9960: Drop GPIO includesLinus Walleij1-2/+0
The driver includes <linux/gpio.h> and <linux/of_gpio.h> yet fails to use symbols from any of the include files, so drop these includes. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: ad2s1200: Drop legacy includeLinus Walleij1-1/+0
This driver is using the GPIO descriptor API but yet includes the legacy <linux/gpio.h> header for no reason. Drop the surplus include. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: si1145: Drop GPIO includeLinus Walleij1-1/+0
The driver include <linux/gpio.h> yet does not use any of the symbols from the header, so drop the include. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: as3935: Drop GPIO includesLinus Walleij1-3/+0
The driver includes <linux/gpio.h> and <linux/of_gpio.h> yet fails to use symbols from any of the include files, so drop these includes. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: imu: st_lsm6dsx: fix checkpatch warningLorenzo Bianconi1-5/+5
Fix following checkpatch warning: CHECK: Alignment should match open parenthesis +static int st_lsm6dsx_read_event(struct iio_dev *iio_dev, + const struct iio_chan_spec *chan, Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-15iio: ak8975: Convert to use GPIO descriptorLinus Walleij1-35/+19
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>
2019-12-15iio: adc: ad799x: add pm_ops to disable the device completelyMarco Felsch1-6/+60
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>
2019-12-15iio: imu: inv_mpu6050: Select I2C_MUX againLinus Walleij1-1/+2
commit f7072198f217 ("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 93d710a65ef0 ("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>
2019-12-15iio: adc: ad7887: Cleanup channel assignmentBeniamin Bia1-39/+43
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>
2019-12-09Merge tag 'iio-fixes-for-5.5a' of ↵Greg Kroah-Hartman14-63/+139
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan writes: First set of fixes for IIO in the 5.5 cycle. Mixture of old things people have just hit, and a few late breaking issues with things that went in during the merge window. Being sent promptly to resolve potential DT breakage causing issues for binding test builds. * ad7606 - Avoid reading extra data from the device over what was intended. * ad7124 - Enable the internal reference when in use. * ad7292 - Fix up license for newly added binding. Better to not have this go out in a release with more limited header than intended. - Fix a constraint on number of channels. * ad7949 - Fix an issue which can result in readouts being from the wrong channel. * hdc100x - Fix wrong ABI usage (units) for relative humidity channel. * intel mrfld - Allocate right amount of private data (currently allocating too much). * ltc2983 - Avoid a potential issue with machine endianness and wrong length device tree read. * max1027 - Clean up leak of an iio_trigger on probe failure. * max9611 - Ensure we sleep long enough to successfully initialize the sensor. * mpu6050 - Fix wrong ABI usage (units) for temperature channel. * st_accel - Fix an unused variable warning. * st_lsm6dsx - Fix decimation factor issue that can lead to missaligned datasets (and hence garbage) - Fix an issue with how we track enabled fifo channels. - Avoid powering off the device if wake up events are enabled. * tag 'iio-fixes-for-5.5a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: adc: max9611: Fix too short conversion time delay iio: ad7949: fix channels mixups iio: imu: st_lsm6dsx: do not power-off accel if events are enabled iio: imu: st_lsm6dsx: track hw FIFO buffering with fifo_mask iio: imu: st_lsm6dsx: fix decimation factor estimation iio: imu: inv_mpu6050: fix temperature reporting using bad unit iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting iio: adc: max1027: fix not unregistered iio trigger iio: adc: intel_mrfld_adc: Allocating too much data in probe() iio: adc: ad7124: Enable internal reference dt-bindings: iio: adc: ad7292: fix constraint over channel quantity dt-bindings: iio: adc: ad7292: Update SPDX identifier iio: temperature: ltc2983: fix u32 read into a unsigned long long iio: st_accel: Fix unused variable warning iio: adc: ad7606: fix reading unnecessary data from device
2019-12-08iio: adc: max9611: Fix too short conversion time delayGeert Uytterhoeven1-6/+10
As of commit b9ddd5091160793e ("iio: adc: max9611: Fix temperature reading in probe"), max9611 initialization sometimes fails on the Salvator-X(S) development board with: max9611 4-007f: Invalid value received from ADC 0x8000: aborting max9611: probe of 4-007f failed with error -5 The max9611 driver tests communications with the chip by reading the die temperature during the probe function, which returns an invalid value. According to the datasheet, the typical ADC conversion time is 2 ms, but no minimum or maximum values are provided. Maxim Technical Support confirmed this was tested with temperature Ta=25 degreeC, and promised to inform me if a maximum/minimum value is available (they didn't get back to me, so I assume it is not). However, the driver assumes a 1 ms conversion time. Usually the usleep_range() call returns after more than 1.8 ms, hence it succeeds. When it returns earlier, the data register may be read too early, and the previous measurement value will be returned. After boot, this is the temperature POR (power-on reset) value, causing the failure above. Fix this by increasing the delay from 1000-2000 µs to 3000-3300 µs. Note that this issue has always been present, but it was exposed by the aformentioned commit. Fixes: 69780a3bbc0b1e7e ("iio: adc: Add Maxim max9611 ADC driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-08iio: ad7949: fix channels mixupsAndrea Merello1-5/+17
Each time we need to read a sample (from the sysfs interface, since the driver supports only it) the driver writes the configuration register with the proper settings needed to perform the said read, then it runs another xfer to actually read the resulting value. Most notably the configuration register is updated to set the ADC internal MUX depending by which channel the read targets. Unfortunately this seems not enough to ensure correct operation because the ADC works in a pipelined-like fashion and the new configuration isn't applied in time. The ADC alternates two phases: acquisition and conversion. During the acquisition phase the ADC samples the analog signal in an internal capacitor; in the conversion phase the ADC performs the actual analog to digital conversion of the stored voltage. Note that of course the MUX needs to be set to the proper channel when the acquisition phase is performed. Once the conversion phase has been completed, the device automatically switches back to a new acquisition; on the other hand the device switches from acquisition to conversion on the rising edge of SPI cs signal (that is when the xfer finishes). Only after both two phases have been completed (with the proper settings already written in the configuration register since the beginning) it is possible to read the outcome from SPI bus. With the current driver implementation, we end up in the following situation: _______ 1st xfer ____________ 2nd xfer ___________________ SPI cs.. \_________/ \_________/ SPI rd.. idle |(val N-2)+ idle | val N-1 + idle ... SPI wr.. idle | cfg N + idle | (X) + idle ... ------------------------ + -------------------- + ------------------ AD .. acq N-1 + cnv N-1 | acq N + cnv N | acq N+1 As shown in the diagram above, the value we read in the Nth read belongs to configuration setting N-1. In case the configuration is not changed (config[N] == config[N-1]), then we still get correct data, but in case the configuration changes (i.e. switching the MUX on another channel), we get wrong data (data from the previously selected channel). This patch fixes this by performing one more "dummy" transfer in order to ending up in reading the data when it's really ready, as per the following timing diagram. _______ 1st xfer ____________ 2nd xfer ___________ 3rd xfer ___ SPI cs.. \_________/ \_________/ \_________/ SPI rd.. idle |(val N-2)+ idle |(val N-1)+ idle | val N + .. SPI wr.. idle | cfg N + idle | (X) + idle | (X) + .. ------------------------ + -------------------- + ------------------- + -- AD .. acq N-1 + cnv N-1 | acq N + cnv N | acq N+1 | .. NOTE: in the latter case (cfg changes), the acquisition phase for the value to be read begins after the 1st xfer, that is after the read request has been issued on sysfs. On the other hand, if the cfg doesn't change, then we can refer to the fist diagram assuming N == (N - 1); the acquisition phase _begins_ before the 1st xfer (potentially a lot of time before the read has been issued via sysfs, but it _ends_ after the 1st xfer, that is _after_ the read has started. This should guarantee a reasonably fresh data, which value represents the voltage that the sampled signal has after the read start or maybe just around it. Signed-off-by: Andrea Merello <andrea.merello@gmail.com> Reviewed-by: Charles-Antoine Couret <charles-antoine.couret@essensium.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-08iio: imu: st_lsm6dsx: do not power-off accel if events are enabledLorenzo Bianconi1-4/+26
Do not power-off accel unconditionally if wake-up events are enabled powering off the hw FIFO. At the same time do not power-off the accel sensor if it is 'batched' in the hw FIFO disabling sensor events Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events") Tested-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-08iio: imu: st_lsm6dsx: track hw FIFO buffering with fifo_maskLorenzo Bianconi3-15/+18
Track hw FIFO state introducing fifo_mask since now the accel sensor can be enabled during suspend/resume in order to trigger the wake-up enabling the FIFO in st_lsm6dsx_resume even if it was disabled before the suspend. Hence we must separately track the fifo state. Fixes: 4c997dfa692d ("iio: imu: st_lsm6dsx: add wakeup-source option") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Tested-by: Sean Nyekjaer <sean@geanix.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-12-08iio: imu: st_lsm6dsx: fix decimation factor estimationLorenzo Bianconi2-9/+18
Fix decimation factor and sip estimation for LSM6DSM series (max value for decimation factor is 32). If gyro and accel sensors are enabled at 12.5Hz and 416Hz respectively, decimation factor lookup will fail, producing unaligned data. Remove unused decimator filed in st_lsm6dsx_sensor structure. Fixes: f8710f0357bc ("iio: imu: st_lsm6dsx: express odr in mHZ") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-05 00:40:28 +0000