- 05 Oct, 2023 10 commits
-
-
Matti Vaittinen authored
Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure pressures ranging from 300 hPa to 1300 hPa with configurable measurement averaging and internal FIFO. The sensor does also provide temperature measurements. Sensor does also contain IIR filter implemented in HW. The data-sheet says the IIR filter can be configured to be "weak", "middle" or "strong". Some RMS noise figures are provided in data sheet but no accurate maths for the filter configurations is provided. Hence, the IIR filter configuration is not supported by this driver and the filter is configured to the "middle" setting (at least not for now). The FIFO measurement mode is only measuring the pressure and not the temperature. The driver measures temperature when FIFO is flushed and simply uses the same measured temperature value to all reported temperatures. This should not be a problem when temperature is not changing very rapidly (several degrees C / second) but allows users to get the temperature measurements from sensor without any additional logic. This driver allows the sensor to be used in two muitually exclusive ways, 1. With trigger (data-ready IRQ). In this case the FIFO is not used as we get data ready for each collected sample. Instead, for each data-ready IRQ we read the sample from sensor and push it to the IIO buffer. 2. With hardware FIFO and watermark IRQ. In this case the data-ready is not used but we enable watermark IRQ. At each watermark IRQ we go and read all samples in FIFO and push them to the IIO buffer. Signed-off-by:
Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/4f23211e3cf248f9f48ddb2a752387bb00e9c2c4.1695727471.git.mazziesaccount@gmail.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
BM1390GLV-Z is a pressure sensor which performs internal temperature compensation for the MEMS. Pressure range is from 300 hPa to 1300 hPa and sample averaging and IIR filtering is built in sensor. Temperature measurement is also supported. Add dt-bindings for the sensor. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/08796e6b28d2c67933b1a1a5eca0f43da322a597.1695727471.git.mazziesaccount@gmail.comSigned-off-by:
-
Matti Vaittinen authored
The available_scan_mask is an array of bitmaps representing the channels which can be simultaneously enabled by the driver. In many cases, the hardware can offer more channels than what the user is interested in obtaining. In such cases, it may be preferred that only a subset of channels are enabled, and the driver reads only a subset of the channels from the hardware. Some devices can't support all channel combinations. For example, the BM1390 pressure sensor must always read the pressure data in order to acknowledge the watermark IRQ, while reading temperature can be omitted. So, the available scan masks would be 'pressure and temperature' and 'pressure only'. When IIO searches for the scan mask it asks the driver to use, it will pick the first suitable one from the 'available_scan_mask' array. Hence, ordering the masks in the array makes a difference. We should 'prefer' reading just the pressure from the hardware (as it is a cheaper operation than reading both pressure and temperature) over reading both pressure and temperature. Hence, we should set the 'only pressure' as the first scan mask in available_scan_mask array. If we set the 'pressure and temperature' as first in the array, then the 'only temperature' will never get used as 'pressure and temperature' can always serve the user's needs. Add (minimal) kerneldoc to the 'available_scan_mask' to hint the user that the ordering of masks matters. Signed-off-by:
-
Andreas Kemnade authored
Some boards fail in magnetometer probe if level shifter flag is not set, definition was found in the vendor Linux kernel v3.0. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by:
Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20230927173245.2151083-3-andreas@kemnade.infoSigned-off-by:
-
Andreas Kemnade authored
Add a level shifter flag as found in ancient platform data struct: level_shifter: 0: VLogic, 1: VDD Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Antoniu Miclaus authored
The http://ez.analog.com/community/linux-device-drivers link is broken. Update website link to the new available one: https://ez.analog.com/linux-software-driversSigned-off-by:
Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20230926100149.4611-1-antoniu.miclaus@analog.comSigned-off-by:
-
Ramona Gradinariu authored
The temperature channel has 16-bit storage size. We need to perform the padding to have the buffer elements naturally aligned in case the temperature channel is enabled and there are any 32-bit storage size channels enabled which have a scan index higher than the temperature channel scan index. Fixes: 8f6bc87d ("iio: imu: adis16475.c: Add delta angle and delta velocity channels") Signed-off-by:
Ramona Gradinariu <ramona.gradinariu@analog.com> Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20230926085721.645687-2-ramona.gradinariu@analog.comSigned-off-by:
-
David Lechner authored
This modifies the ad2s1210_show_fexcit() function to read the excitation frequency from the control register. This way we don't have to keep track of the value and don't risk returning a stale value. Signed-off-by:
David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-16-fa4364281745@baylibre.comSigned-off-by:
-
David Lechner authored
This combines the ad2s1210_update_frequency_control_word() and ad2s1210_soft_reset() functions into a single function since they both have to be called together. (The software reset does not reset any configuration registers, it only updates the excitation output and resets the tracking loop.) Also clean up a few things while touching this: - move AD2S1210_DEF_EXCIT macro with similar macros - remove unnecessary dev_err() calls Signed-off-by:
-
David Lechner authored
- Remove "adi," prefix from gpio names. - Sample gpio is now expected to be active low. - Convert A0 and A1 gpios to "mode-gpios" gpio array. - Convert RES0 and RES1 gpios to "resolution-gpios" gpio array. - Remove extraneous lookup tables. - Remove unused mode field from state struct. - Swap argument order of ad2s1210_set_mode() while we are touching this. Signed-off-by:
-
- 30 Sep, 2023 11 commits
-
-
David Lechner authored
This removes the config register sysfs attribute. Writing to the config register directly can be dangerous and userspace should not need to have to know the register layout. This register can still be accessed though debugfs if needed. We can add new attributes to set specific flags in the config register in the future if needed (e.g. `enable_hysterisis` and `phase_lock_range`). Signed-off-by:
-
David Lechner authored
This add an implementation of debugfs_reg_access for the AD2S1210 driver. Signed-off-by:
-
David Lechner authored
This makes use of the regmap API to read and write the configuration registers. This simplifies code quite a bit and makes it safer (previously, it was easy to write a bad value to the config registers which causes the chip to lock up and need to be reset). This chip has multiple modes of operation. In normal mode, we do not use regmap since there is no addressing - data is just bitshifted out during the SPI read. In config mode, we use regmap since it requires writing the address (with read/write flag) before reading and writing. We don't use the lock provided by the regmap because we need to also synchronize with the normal mode SPI reads and with the various GPIOs. There is also a quirk when reading registers (other than the fault register). If the address/data bit is set in the value read, then it indicates there is a configuration parity error and the data is not valid. Previously, this was checked in a few places, but not consistently. Now, we always check it in the regmap read function. Signed-off-by:
-
David Lechner authored
This removes the fclkin sysfs attribute and replaces it with getting the CLKIN clock rate using the clk subsystem (i.e. from the devicetree). CLKIN comes from an external oscillator that is connected directly to the AD2S1210 chip, so users of the sysfs attributes should not need to be concerned with this. The fclkin field (the datasheet name) is renamed to clkin_hz to be more obvious that it is a frequency in Hz. Signed-off-by:
-
David Lechner authored
This adds an implementation of IIO_CHAN_INFO_SCALE to the ad2s1210 resolver driver. This allows userspace to get the scale factor for the raw values. Signed-off-by:
-
David Lechner authored
This removes the special handling for resolutions lower than 16 bits. This will allow us to use a fixed scale independent of the resolution. A new sample field is added to store the raw data instead of reusing the config mode rx buffer so that we don't have to do a cast or worry about unaligned access. Also, for the record, according to the datasheet, the logic for the special handling based on hysteresis that was removed was incorrect. Signed-off-by:
-
David Lechner authored
There are quite a few imports and we will be adding more so it will make it easier to read if they are sorted. Signed-off-by:
-
David Lechner authored
Since we never call spi_get_drvdata(), we can remove spi_set_drvdata(). Signed-off-by:
-
David Lechner authored
This adds a check to the return value of ad2s1210_initial() since it can fail. The call is also moved before devm_iio_device_register() so that we don't have to unregister the device if it fails. Signed-off-by:
-
David Lechner authored
This removes the call to spi_setup() in the ad2s1210 driver. Setting MODE_3 was incorrect. It should be MODE_1 but we can let the device tree select this and avoid the need to call spi_setup(). Signed-off-by:
-
David Lechner authored
This fixes a use before initialization in ad2s1210_probe(). The ad2s1210_setup_gpios() function uses st->sdev but it was being called before this field was initialized. Signed-off-by:
-
- 24 Sep, 2023 13 commits
-
-
David Lechner authored
In theory, this code path should not be reachable because of the previous switch statement. But just in case we should make sure we are restoring the SAMPLE gpio to its original state before returning in addition to releasing the mutex lock. Signed-off-by:
-
David Lechner authored
When reading the fault attribute, an empty string was printed if the fault register value was non-zero. This is fixed by checking that the return value is less than zero instead of not zero. Also always print two hex digits while we are touching this line. Signed-off-by:
-
Marius Cristea authored
The patch 33ec3e5f: "iio: adc: adding support for MCP3564 ADC" from Aug 29, 2023 (linux-next), leads to the following Smatch static checker warning: drivers/iio/adc/mcp3564.c:1426 mcp3564_probe() warn: address of NULL pointer 'indio_dev' drivers/iio/adc/mcp3564.c 1421 struct iio_dev *indio_dev; 1422 struct mcp3564_state *adc; 1423 1424 indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*adc)); 1425 if (!indio_dev) { --> 1426 dev_err_probe(&indio_dev->dev, PTR_ERR(indio_dev), ^^^^^^^^^^^^^^^ Fixes: 33ec3e5f (iio: adc: adding support for MCP3564 ADC) Signed-off-by:
Marius Cristea <marius.cristea@microchip.com> Link: https://lore.kernel.org/r/20230918075633.1884-1-marius.cristea@microchip.comSigned-off-by:
-
Jonathan Cameron authored
The deta angle and deta velocity channels were added in parallel with color temperature and chromacity so this merge had to assign a consistent order. I put the color related ones second. Signed-off-by: -
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add light chromaticity x and y for SFH1.1. Signed-off-by:
Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20230919081054.2050714-10-Basavaraj.Natikar@amd.comSigned-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add light chromaticity x and y. Signed-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add light chromaticity x and y. Signed-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add channel type for chromaticity. Signed-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature. As a result, add support of light color temperature for SFH1.1. Signed-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature. As a result, add support of light color temperature. Signed-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature. As a result, add support of light color temperature. Signed-off-by:
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature, which is measured in kelvin. Thus, add channel type light color temperature. Signed-off-by:
-
Basavaraj Natikar authored
Sensor hub attributes can be extended to support more channels. Repeat the reading for the two existing channels and store them separately. It still operates in the same manner as before where there was just one entry. So in order to support more sensor hub attributes for ALS use channel index to get specific sensor hub attributes. Signed-off-by:
-
- 23 Sep, 2023 6 commits
-
-
Andy Shen Shen authored
In line 460 of the palmas_gpadc.c file, fix kernel comment errors. Signed-off-by:
Andy Shen Shen <shengaoya@inspur.com> Link: https://lore.kernel.org/r/20230921031444.63594-1-shengaoya@inspur.comSigned-off-by:
-
Marek Vasut authored
The ADS1015 can have optional IRQ line connected, document it in the DT bindings. Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230919174931.1417681-50-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
