- 23 May, 2023 6 commits
-
-
Marek Vasut authored
Add support for MLX90615 Infra Red Thermometer, which seems to be the predecesor of MLX90614 . There are significant differences in the register layout compared to MLX90614, but the functionality of the device is virtually identical. The following differences have been identified: - RAM/EEPROM/SLEEP access opcodes are different - RAM/EEPROM registers are at different offsets - EEPROM emissivity and configuration registers are at different offsets - EEPROM configuration register bits are shuffled around - EEPROM emissivity settings are 14 bit on MLX90615 , 16 bit on MLX90614 - MLX90615 can only ever support one sensor, MLX90614 could support two - FIR filter is set to fixed settings on MLX90615 - IIR filter coefficients are different This patch fills in the MLX90615 specific description and quirk handling. The IIR filter coefficients were provided by Melexis as follows: 0b0000 - Forbidden value 0b0001 - 100% - settling time = refresh rate = 205ms (around 5Hz) 0b0010 - 50% - settling time = 2050ms (around 0.5Hz) 0b0011 - 33% - settling time = 36900ms (around 0.3Hz) 0b0100 - 25% - settling time = 5125ms (around 0.2Hz) 0b0101 - 20% - settling time = 6355ms (around 0.15Hz) 0b0110 - 17% - settling time = 7790ms (around 0.13Hz) 0b0111 - 14% - settling time = 9225ms (around 0.1Hz) Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Crt Mori <cmo@melexis.com> Link: https://lore.kernel.org/r/20230510102251.10118-6-marex@denx.deSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marek Vasut authored
Factor out all the differences between MLX90614 and other similar chips into a structure which describes the chip and allows abstracting out the differences from the driver code. No functional change. This patch moves all the RAM and EEPROM IO opcodes into the descriptor structure and combines them, instead of combining the opcode and offset in macros. Acked-by:
-
Marek Vasut authored
The MLX90614_CONST_EMISSIVITY_RESOLUTION can be calculated from MLX90614_CONST_RAW_EMISSIVITY_MAX, perform the calculation inline and drio the MLX90614_CONST_EMISSIVITY_RESOLUTION. Signed-off-by:
-
Marek Vasut authored
To simplify addition of support for new parts, drop unused register macros. No functional change. Acked-by:
-
Marek Vasut authored
Sort the headers alphabetically. No functional change. Acked-by:
-
Marek Vasut authored
Document support for MLX90615 Infra Red Thermometer, which seems to be the predecesor of MLX90614 . There are significant differences in the register layout compared to MLX90614, but the functionality of the device is virtually identical. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
- 21 May, 2023 4 commits
-
-
Andreas Klinger authored
Add myself as a maintainer for Honeywell mprls0025pa sensor. Signed-off-by:
Andreas Klinger <ak@it-klinger.de> Link: https://lore.kernel.org/r/ZGNp+1uNAxi3uxjM@arbadSigned-off-by:
-
Andreas Klinger authored
Honeywell mprls0025pa is a series of pressure sensors. Add initial I2C support. Note: - IIO buffered mode is supported - SPI mode is not supported Signed-off-by:
-
Andreas Klinger authored
Honeywell mprls0025pa is a pressure sensor series. There are many different models with different pressure ranges, units and transfer functions. The range and transfer function need to be set up in the dt. Therefore new properties honeywell,pmin-pascal, honeywell,pmax-pascal, honeywell,transfer-function are introduced. Add dt-bindings. Reviewed-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230515205048.19561-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
- 20 May, 2023 4 commits
-
-
Niklas Schnelle authored
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by:
Arnd Bergmann <arnd@kernel.org> Signed-off-by:
Niklas Schnelle <schnelle@linux.ibm.com> Link: https://lore.kernel.org/r/20230516110038.2413224-13-schnelle@linux.ibm.comSigned-off-by:
-
Krzysztof Kozlowski authored
Reference iio.yaml schema from dtschema to allow already used mount-matrix property: msm8953-xiaomi-daisy.dtb: imu@6a: Unevaluated properties are not allowed ('mount-matrix' was unexpected) Signed-off-by:Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230507173923.263741-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Herve Codina authored
After contributing the driver, add myself as the maintainer for the Renesas X9250 IIO driver. Signed-off-by:
Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/20230509160852.158101-4-herve.codina@bootlin.comSigned-off-by:
-
Herve Codina authored
The Renesas X9250 integrates four digitally controlled potentiometers. On each potentiometer, the X9250T has a 100 kOhms total resistance and the X9250U has a 50 kOhms total resistance. Signed-off-by:
-
- 13 May, 2023 26 commits
-
-
Herve Codina authored
The Renesas X9250 is a quad digitally controlled potentiometers. Signed-off-by:
-
Hermes Zhang authored
The Invensense ICM-20600 is a 6-axis MotionTracking device that combines a 3-axis gyroscope and an 3-axis accelerometer. It is very similar to the ICM20602 imu which is already supported by the mpu6050 driver. The main difference is that the ICM-20600 has a different WHOAMI value. Signed-off-by:
Hermes Zhang <chenhuiz@axis.com> Acked-by:
Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20230505054853.2155326-3-chenhuiz@axis.comSigned-off-by:
-
Hermes Zhang authored
ICM-20600 is almost same as ICM-20602 which already support in mpu6050 driver. Specify "invensense,icm20602" as a fallback compatible Signed-off-by:
-
Marijn Suijten authored
Set the read_label() callback to return a friendly name provided in DT (firmware), in order to make in_{therm,voltage}X_label attributes show up in sysfs for userspace to consume a channel name. This is particularly useful for custom thermistors being attached to otherwise generically named GPIOs, where the name is known by the board DT. If the channel name isn't set in DT, use the datasheet_name hardcoded in the driver instead. Note that this doesn't fall back to fwnode_get_name() as that provides suboptimally readable names, with an @xx address suffix from board DT. Signed-off-by:Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20230502-iio-adc-propagate-fw-node-label-v3-5-6be5db6e6b5a@somainline.orgSigned-off-by:
-
Marijn Suijten authored
datasheet_name is statically filled by a macro for every channel, and is nor should ever be set to NULL. Signed-off-by:
-
Marijn Suijten authored
Since the migration to fwnode_get_name in commit 4f47a236 ("iio: adc: qcom-spmi-adc5: convert to device properties") the resulting adc5_channel_prop::channel_name (renamed from datasheet_name in the previous patch) - which is propagated into iio_chan_spec::extend_name - was containing the DT node name including @xx suffix if a "label" property is not present, while adc5_channels::datasheet_name was thus far set by the macros but always remained unread. Put it to use instead of using a confusing name containing @xx in sysfs filenames (again, when "label" is not set). Signed-off-by:
-
Marijn Suijten authored
iio_chan_spec::datasheet_name expects a channel/pin name on the hardware part, i.e. from its datasheet, instead of a friendly name from DT which typically describes the use of said channel. GPIO channels are commonly specialized in QCOM board DTS based on what a - typically thermistor - is connected to. Also rename adc5_channel_prop::datasheet_name to channel_name to that effect. Signed-off-by:
-
Marijn Suijten authored
As mentioned and discussed in [1] extend_name should not be used for full channel labels (and most drivers seem to only use it to express a short type of a channel) as this affects sysfs filenames, while the label name is supposed to be extracted from the *_label sysfs file instead. This appears to have been unclear to some drivers as extend_name is also used when read_label is unset, achieving an initial goal of providing sensible names in *_label sysfs files without noticing that sysfs filenames are (negatively and likely unintentionally) affected as well. Point readers of iio_chan_spec::extend_name to iio_info::read_label by mentioning deprecation and side-effects of this field. [1]: https://lore.kernel.org/linux-arm-msm/20221221223432.si2aasbleiicayfl@SoMainline.org/Suggested-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Matti Vaittinen authored
Devices which may take a while to initialize during probe and which have no strong reason to probe synchronously can request asynchronous probing as default probe strategy. This can speed-up start times on some platforms. The KX022A gets probe delayed for at least two reasons. It enables the supply regulator, (which is likely to have ramp-up delay if it was disabled) and additionally it delays while the sensor itself is initializing. Changing to asynchronous probing may cause problems. Some of which are discussed in: https://lore.kernel.org/all/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/ Enable asynchronous probing for KX022A. Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/24cea76c282a28b7a4dba297ab627176f8097907.1683185765.git.mazziesaccount@gmail.comSigned-off-by:
-
Matti Vaittinen authored
Devices which may take a while to initialize during probe and which have no strong reason to probe synchronously can request asynchronous probing as default probe strategy. This can speed-up start times on some platforms. The BU27034 gets probe delayed for at least two reasons. It enables the supply regulator, (which is likely to have ramp-up delay if it was disabled) and additionally it delays while the sensor itself is initializing. Changing to asynchronous probing may cause problems. Some of which are discussed in: https://lore.kernel.org/all/06db017f-e985-4434-8d1d-02ca2100cca0@sirena.org.uk/ Enabling async probing for the ROHM BU27034 should be fairly safe to try though as there is no in-tree users for it yet. If the async probing appears to be an issue we can switch easily back to synchronous (or better yet, fix the actual problem). Enable asynchronous probing for BU27034. Signed-off-by:
-
Marijn Suijten authored
As discussed in [1] it is more convenient to use a generic `channel` node name for ADC channels while storing a friendly - board-specific instead of PMIC-specific - name in the label, if/when desired to overwrite the channel description already contained (but previously unused) in the driver [2]. The same `channel` node name pattern has also been set in iio/adc/adc.yaml, but this generic binding is not inherited as base for qcom,spmi-vadc bindings due to not having any other generic elements in common, besides the node name rule and reg property. Replace the .* name pattern with the `channel` literal, but leave the label property optional for bindings to choose to fall back a channel label hardcoded in the driver [2] instead. [1]: https://lore.kernel.org/linux-arm-msm/20221106193018.270106-1-marijn.suijten@somainline.org/T/#u [2]: https://lore.kernel.org/linux-arm-msm/20230116220909.196926-4-marijn.suijten@somainline.org/Signed-off-by:
-
Nuno Sá authored
Just cosmetics. No functional change intended... Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Reviewed-by:
Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20230216101452.591805-4-nuno.sa@analog.comSigned-off-by:
-
Stefan Windfeldt-Prytz authored
This driver uses the continuous mode of the chip and integration time can be configured through sysfs. The constants for calculating lux value differs between packaging so it uses different compatible string for the two versions "ti,opt4001-picostar" and "ti,opt4001-sot-5x3" since the device id is the same. Datasheet: https://www.ti.com/lit/gpn/opt4001Signed-off-by:
Stefan Windfeldt-Prytz <stefan.windfeldt-prytz@axis.com> Link: https://lore.kernel.org/r/20230323-add-opt4001-driver-v3-2-62e121dab294@axis.comSigned-off-by:
-
Stefan Windfeldt-Prytz authored
Add devicetree bindings for opt4001 ambient light sensor. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230323-add-opt4001-driver-v3-1-62e121dab294@axis.comSigned-off-by:
-
Christophe JAILLET authored
This driver does not use i2c, so there is no point in including <linux/i2c.h> Remove it. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/9d23cd04d7f99dc8d813584aae5268b57f92fcd8.1682320298.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Frank Wunderlich authored
Add compatible string and specific clock property for mt7986. Signed-off-by:
Frank Wunderlich <frank-w@public-files.de> Link: https://lore.kernel.org/r/20230421132047.42166-3-linux@fw-web.deSigned-off-by:
-
Sean Nyekjaer authored
Since nearly all stm32 dt's are using the legacy adc channel config, we should warn users about using it. Signed-off-by:
Sean Nyekjaer <sean@geanix.com> Link: https://lore.kernel.org/r/20230421083858.2613289-1-sean@geanix.comSigned-off-by:
-
Marius Hoch authored
This sensor can be found as CALS0001 on the Lenovo Yoga Tablet 2 series. Tested on a Lenovo Yoga Tablet 2 1051-F. Signed-off-by:
Marius Hoch <mail@mariushoch.de> Tested-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Christophe JAILLET authored
dev_err_probe() already display the error code. There is no need to duplicate it explicitly in the error message. Signed-off-by:
-
Marius Hoch authored
Same as the lsm9ds0, except that the lsm303d doesn't feature a gyroscope. Signed-off-by:
Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20230415231130.115094-7-mail@mariushoch.deSigned-off-by:
-
Marius Hoch authored
Per its datasheet, the LSM303D also features that pin. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Tested-by:
-
Marius Hoch authored
The lsm303d can be found as ACCL0001 on various Lenovo devices, including the Lenovo Yoga Tablet 2 1051-F, where I tested this patch. Dropped SPI support as per discussion in thread linked below. Signed-off-by:
-
Marius Hoch authored
The lsm303d is basically the lsm9ds0 without the gyroscope (which the LSM9DS0 IMU driver doesn't handle), as far as I can tell. Signed-off-by:
-
Marius Hoch authored
The lsm303d has the same register mapping as the lsm9ds0, thus we can just re-use that. Tested on a Lenovo Yoga Tablet 2 1051-F. Signed-off-by:
-
Marius Hoch authored
The lsm303d has the same register mapping as the lsm9ds0, thus we can just re-use that. Tested on a Lenovo Yoga Tablet 2 1051-F. Signed-off-by:
-
Luca Weiss authored
The channel ADC5_USB_IN_V_16 is using 1/16 pre-scaling on at least pm7250b and pmi632. Allow that in the schema. Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Acked-by:
-
