When reading in_voltage_scale we can get something like:
root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale
0.038146
However, when reading the available options:
root@analog:/sys/bus/iio/devices/iio:device2# cat
in_voltage_scale_available
2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010
which does not make sense. Moreover, when trying to set a new scale we
get an error because there's no call to __ad9467_get_scale() to give us
values as given when reading in_voltage_scale. Fix it by computing the
available scales during probe and properly pass the list when
.read_available() is called.
While at it, change to use .read_available() from iio_info. Also note
that to properly fix this, adi-axi-adc.c has to be changed accordingly.
Fixes: ad67971202 ("iio: adc: ad9467: add support AD9467 ADC")
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-4-a4a33bc4d70e@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The reset gpio was being handled with inverted polarity. This means that
as far as gpiolib is concerned we were actually leaving the pin asserted
(in theory, this would mean reset). However, inverting the polarity in
devicetree made things work. Fix it by doing it the proper way and how
gpiolib expects it to be done.
While at it, moved the handling to it's own function and dropped
'reset_gpio' from the 'struct ad9467_state' as we only need it during
probe. On top of that, refactored things so that we now request the gpio
asserted (i.e in reset) and then de-assert it. Also note that we now use
gpiod_set_value_cansleep() instead of gpiod_direction_output() as we
already request the pin as output.
Fixes: ad67971202 ("iio: adc: ad9467: add support AD9467 ADC")
Reviewed-by: David Lechner <dlechner@baylibre.com>
Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-1-a4a33bc4d70e@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The Vishay VEMl6075 is a low power, 16-bit resolution UVA and UVB
light sensor with I2C interface and noise compensation (visible and
infrarred).
Every UV channel generates an output signal measured in counts per
integration period, where the integration time is configurable.
This driver adds support for both UV channels and the ultraviolet
index (UVI) inferred from them according to the device application note
with open-air (no teflon) coefficients.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231110-veml6075-v3-3-6ee46775b422@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Currently there are only two modifiers for ultraviolet light: a generic
one for any ultraviolet light (IIO_MOD_LIGHT_UV) and one for deep
ultraviolet (IIO_MOD_LIGHT_DUV), which is also referred as ultraviolet
C (UV-C) band and covers short-wave ultraviolet.
There are still no modifiers for the long-wave and medium-wave
ultraviolet bands. These two bands are the main components used to
obtain the UV index on the Earth's surface.
Add modifiers for the ultraviolet A (UV-A) and ultraviolet B (UV-B)
bands.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231110-veml6075-v3-1-6ee46775b422@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The example for the TI Palmas ADC is incomplete as the binding is the
full PMIC, not just the sub-functions. It is preferred for MFD examples
to be complete in the top-level MFD device binding rather than piecemeal
in each sub-function binding.
This also fixes an undocumented (by schema) compatible warning for
'"ti,twl6035-pmic", "ti,palmas-pmic"'.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231128214803.3975542-1-robh@kernel.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Commit 33ec3e5fc1 ("iio: adc: adding support for MCP3564 ADC") adds a new
iio driver and corresponding MAINTAINERS section. It however uses spaces
instead of a single tab for all the entries in that MAINTAINERS section.
Although, the get_maintainer.pl script handles spaces instead of tabs
silently, the MAINTAINERS will quickly get into a messy state with
different indentations throughout the file. So, the checkpatch.pl script
complains when spaces instead of a single tab are used.
Fix this recently added section using tabs instead of spaces.
Further, add the driver's ABI documentation file to this section as well.
Fixes: 33ec3e5fc1 ("iio: adc: adding support for MCP3564 ADC")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20231122075629.21411-1-lukas.bulwahn@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
When IIO goes through the available scan masks in order to select the
best suiting one, it will just accept the first listed subset of channels
which meets the user's requirements. If driver lists a mask which is a
subset of some of the masks previously in the array of
avaliable_scan_masks, then the latter one will never be selected.
Add a warning if driver registers masks which can't be used due to the
available_scan_masks-array ordering.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/e55ef0b26a6d3b323bab24920c131c79a01ba08e.1697452986.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The devices supported by adis16475 driver require a stall period
between SPI transactions (during which the chip select is
inactive), with a minimum value equal to 16 microseconds, thus
adding 'spi-cs-inactive-delay-ns' property, which should indicate
the stall time between consecutive SPI transactions.
The specified minimum time may not be sufficient for all
configurations.
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231027140358.328699-3-ramona.gradinariu@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
A delay is needed each time the chip selected becomes inactive,
even after burst data readings are performed.
Currently, there is no delay added after a burst reading
and in case a new SPI transfer is performed before
the needed delay, the adis device becomes unresponsive until
reset.
This commit is adding the needed delay directly to the spi driver,
using the cs_inactive parameter, in case it is not set and is
removing the additional chip select change delay present in adis
APIs to remove the double delay.
Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
Link: https://lore.kernel.org/r/20231027140358.328699-2-ramona.gradinariu@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Commit b512c767e7bc ("iio: imu: Add driver for BMI323 IMU") adds the
MAINTAINERS section BOSCH SENSORTEC BMI323 IMU IIO DRIVER and refers to a
non-existing device-tree file.
Probably, this mistake was introduced by copying from the BOSCH SENSORTEC
BMA400 ACCELEROMETER IIO DRIVER section and missing to adjust the file
entry properly. This is however easily caught, as the script
./scripts/get_maintainer.pl --self-test=patterns complains about a broken
reference.
The related commit 77583938740e ("dt-bindings: iio: imu: Add Bosch BMI323")
adds bosch,bmi323.yaml, so refer to that intended file instead.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Jagath Jog J <jagathjog1996@gmail.com>
Link: https://lore.kernel.org/r/20231025091550.21052-1-lukas.bulwahn@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The RGB + IR data can be used to calculate the illuminance value (luxes).
Implement the equation obtained from the ROHM HW colleagues and add a
raw light data channel outputting illuminance values in (nano) Luxes.
Both the read_raw and buffering values are supported, with the limitation
that buffering is only allowed when a suitable scan-mask is used. (RGB+IR,
no clear).
The equation has been developed by ROHM HW colleagues for open air sensor.
Adding any lens to the sensor is likely to impact to used c1, c2, c3
coefficients. Also, the output values have only been tested on BU27008.
According to the HW colleagues, the very same equation should work on
BU27010 as well.
Calculate and output illuminance values from BU27008 and BU27010.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/ZTJcOxSb/WHzdN8h@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
They are appear to be spelling mistakes,
drivers/iio/pressure/bmp280.h:413 endianess->endianness
drivers/iio/pressure/bmp280-core.c:923 dregrees->degrees
drivers/iio/pressure/bmp280-core.c:1388 reescale->rescale
drivers/iio/pressure/bmp280-core.c:1415 reescale->rescale
Signed-off-by: Li peiyu <579lpy@gmail.com>
Link: https://lore.kernel.org/r/20231021070903.6051-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
