- 25 Jul, 2021 1 commit
-
-
Martin Blumenstingl authored
G12A and newer don't use the SAR ADC to read the SoC temperature from within the firmware. Instead there's now a dedicated thermal sensor. Disable the BL30 integration for G12A and newer SoCs to save a few CPU cycles when reading samples. Adding a separate struct meson_sar_adc_data is a good idea anyways because starting with G12A there's some extra registers to read the samples in a simplified way. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20210717233718.332267-2-martin.blumenstingl@googlemail.comSigned-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 24 Jul, 2021 12 commits
-
-
Alexandru Ardelean authored
The st_gyro_allocate_ring() function calls iio_triggered_buffer_setup() to allocate a triggered buffer. But the same can be done with devm_iio_triggered_buffer_setup() and then the st_gyro_common_remove() no longer needs to manually deallocate it. We know that the parent of the IIO device is used to manage other instances of the devm unwind, so it can be used in the st_gyro_allocate_ring() as well. Signed-off-by:
Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210720074642.223293-4-aardelean@deviqon.comSigned-off-by:
-
Alexandru Ardelean authored
The st_magn_allocate_ring() function calls iio_triggered_buffer_setup() to allocate a triggered buffer. But the same can be done with devm_iio_triggered_buffer_setup() and then the st_magn_common_remove() no longer needs to manually deallocate it. We know that the parent of the IIO device is used to manage other instances of the devm unwind, so it can be used in the st_magn_allocate_ring() as well. This change also removes some omitted st_magn_{probe,remove}_trigger() inline hooks. Signed-off-by: -
Alexandru Ardelean authored
The st_accel_allocate_ring() function calls iio_triggered_buffer_setup() to allocate a triggered buffer. But the same can be done with devm_iio_triggered_buffer_setup() and then the st_accel_common_remove() no longer needs to manually deallocate it. We know that the parent of the IIO device is used to manage other instances of the devm unwind, so it can be used in the st_accel_allocate_ring() as well. Signed-off-by:
-
Alexandru Ardelean authored
The st_press_allocate_ring() function calls iio_triggered_buffer_setup() to allocate a triggered buffer. But the same can be done with devm_iio_triggered_buffer_setup() and then the st_press_common_remove() no longer needs to manually deallocate it. We know that the parent of the IIO device is used to manage other instances of the devm unwind, so it can be used in the st_press_allocate_ring() as well. Signed-off-by:
-
Tang Bin authored
Use the defined variable "dev" to make the code cleaner. Co-developed-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20210720125945.11548-1-tangbin@cmss.chinamobile.comSigned-off-by:
-
Ivan Mikhaylov authored
Remove iio_claim/release and change it on mutex accordingly in vcnl3020_write_proxy_samp_freq. Signed-off-by:
Ivan Mikhaylov <i.mikhaylov@yadro.com> Link: https://lore.kernel.org/r/20210722154420.915082-4-i.mikhaylov@yadro.comSigned-off-by:
-
Ivan Mikhaylov authored
Add the possibility to run proximity sensor in periodic measurement mode with thresholds. Reported-by: kernel test robot <lkp@intel.com> #repeated include Signed-off-by:
-
Ivan Mikhaylov authored
Add DMA safe buffer for bulk transfers. Signed-off-by:
-
Jonathan Cameron authored
The st-sensors drivers have changed in structure over time, and includes have not always kept up with this. Let's bring them back to nearer the ideal. Identified with the include-what-you-use tool and careful checking of its suggestions. Note I haven't been particularly aggressive here, so this is just the cases where the include obviously isn't needed rather than the more subtle corners. Note I took the opportunity to add mod_devicetable.h as I generally prefer to see that when acpi or of match tables are present. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210608175149.4019289-1-jic23@kernel.org
-
Stephan Gerhold authored
In Linux the bma180 and bmc150-accel driver cover fairly similar chips from Bosch (just with minor register differences). For the DT schema, this does not make any difference: They both represent I2C/SPI devices, have one or two interrupts plus a vdd/vddio-supply. This means there is no need to duplicate the schema, we can just document the compatibles for both drivers in a single DT schema. Suggested-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210614163150.7774-4-stephan@gerhold.netSigned-off-by:
-
Stephan Gerhold authored
Similar to recent rework in the bmc150-accel driver, sort the compatible list in the DT schema so there is a consistent order. Signed-off-by:
-
Stephan Gerhold authored
Bosch accelerometers similar to BMA255 are initially configured to emit an active-high interrupt signal. This is currently not re-configured in the bmc150-accel driver so the interrupt should most certainly be IRQ_TYPE_EDGE_RISING (or potentially IRQ_TYPE_LEVEL_HIGH). (Unless there is some kind of inverter installed on the board...) At the moment the bmc150-accel driver forcefully requests the IRQ using IRQF_TRIGGER_RISING, which means that the IRQ type is currently ignored in all existing device trees. Fixes: 6259551c ("iio: accel: bmc150-accel: Add DT bindings") Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 19 Jul, 2021 19 commits
-
-
Colin Ian King authored
The continue statement at the end of a for-loop has no effect, remove it. Addresses-Coverity: ("Continue has no effect") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210617081312.151746-1-colin.king@canonical.comSigned-off-by:
-
Paul Cercueil authored
The point of this new change is to make the IIO tree actually parsable. Before, given this attribute as a filename: in_voltage0_aux_sample_rate Userspace had no way to know if the attribute name was "aux_sample_rate" with no extended name, or "sample_rate" with "aux" as the extended name, or just "rate" with "aux_sample" as the extended name. This was somewhat possible to deduce when there was more than one attribute present for a given channel, e.g: in_voltage0_aux_sample_rate in_voltage0_aux_frequency There, it was possible to deduce that "aux" was the extended name. But even with more than one attribute, this wasn't very robust, as two attributes starting with the same prefix (e.g. "sample_rate" and "sample_size") would result in the first part of the prefix being interpreted as being part of the extended name. To address the issue, knowing that channels will never have both a label and an extended name, set the channel's label to the extended name. In this case, the label's attribute will also have the extended name in its filename, but we can live with that - userspace can open in_voltage0_<prefix>_label and verify that it returns <prefix> to obtain the extended name. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20210618123005.49867-3-paul@crapouillou.netSigned-off-by:
-
Paul Cercueil authored
Extended names are a problem for user-space as they make the filenames in sysfs sometimes not parsable. They are now deprecated in favor of labels. This change makes sure that a device driver won't provide both labels and extended names for its channels. It has never been the case and we don't want it to happen. Signed-off-by:
Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210618123005.49867-2-paul@crapouillou.netSigned-off-by:
-
Baptiste Mansuy authored
Add startup time for each chip familly. This allows a better behaviour of the gyro and the accel. The gyro has now the time to stabilise itself thus making initial data discarding for gyro irrelevant. Signed-off-by:
Baptiste Mansuy <bmansuy@invensense.com> Acked-by:
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Link: https://lore.kernel.org/r/20210621085731.9212-1-bmansuy@invensense.comSigned-off-by:
-
Alexandru Ardelean authored
This driver has two parts, one for i2c and one for spi, since the chip can operate with both wire protocols. The core file has a common adxl345_core_remove() function which puts the chip into a powerdown state. This can be implemented with a devm_add_action_or_reset() hook. Doing that means we can register the IIO device with devm_iio_device_register() and get rid of the adxl345_core_remove() function. The dev_set_drvdata() call can be removed as there is no other user of this private data anymore. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the driver to use only device-managed init routines in the probe function of the driver. This way, we no longer need the tcs3414_remove() hook. We still need to keep the i2c_set_clientdata() call, as that's being used for the PM routines. And lastly, a devm_add_action_or_reset() hook is added to call the powerdown handler when the chip is uninitialized or the probe fails. Signed-off-by:
-
Alexandru Ardelean authored
The change converts the probe function to use the devm_iio_device_register() function. Before calling that, we need to register an action to store the wiper back to non-volatile memory when the device is de-registered. We don't need to do this if the probe fails, because the only place where the probe can fail now is devm_iio_device_register() and that shouldn't create an IIO device (for userspace to poke at) if it fails. Signed-off-by:
-
Alexandru Ardelean authored
When the device is probed, there's no guarantee that the device is not in power-down mode. This can happen if the driver is unregistered and re-probed. To make sure this doesn't happen, the value of the TMP006_CONFIG register (which is read in the probe function and stored in the device's private data) is being checked to see if the MOD bits have the correct value. This is a fix for a somewhat-rare corner case. As it stands, this doesn't look like a high priority to go into the Fixes route. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the driver to register via devm_iio_device_register(). For the tmp006_powerdown() hook, this uses a devm_add_action() hook to put the device in powerdown mode when it's unregistered. With these changes, the remove hook can be removed. The i2c_set_clientdata() call is staying around as the private data is used in the PM routines. Signed-off-by:
-
Alexandru Ardelean authored
The datasheet mentions that the suspend mode is toggled by reading the suspend register. The reading returns value 0xFF if the system was in suspend mode, otherwise it returns value 0x00. The bma220_deinit() function does up to 2 reads, in case the device was in suspend mode, which suggests a level of paranoia that makes the logic in bma220_suspend() and bma220_resume() look insufficient. This change implements a bma220_power() function which does up to 2 reads of the suspend register to make sure that the chip enters a desired (suspended or normal) mode. If the transition fails, then -EBUSY is returned. Since only a reference to SPI device is required, we can remove the spi_set_drvdata() call and get the SPI device object from the base device object in the suspend/resume routines. Signed-off-by:
-
Alexandru Ardelean authored
This change converts the driver to use devm_iio_triggered_buffer_setup() and devm_iio_device_register() for initializing and registering the IIO device. The bma220_deinit() is converted into a callback for a devm_add_action_or_reset() hook, so that the device is put in stand-by when the driver gets uninitialized. The return value of the bma220_deinit() function isn't used as it does not add any value. On the error path of the probe function, this can just override the actual error with -EBUSY, or can even return 0 (no error), on the error path. Signed-off-by:
-
Jonathan Cameron authored
Simple binding for this family of microchip DACs. Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20210627163244.1090296-16-jic23@kernel.org
-
Jonathan Cameron authored
This device was missing a binding document. Simple binding with the ad8803 requiring two both low and high references whilst the 8801 only has a high reference. Signed-off-by:
-
Jonathan Cameron authored
Documenting existing bindings for this device. The Linux driver in theory 'works' without the two supplies that I have listed as required, but without a valid scale. As such I've documented it as required. Signed-off-by:
-
Jonathan Cameron authored
This binding covers the ad5744, ad5744r, ad5764 and ad5764r DACs. Note that the driver currently assumes the internal reference is used for the r parts. The binding as defined relaxes this constraint. There is no support in the binding or driver for the two digital IO signals. I do not propose to add that until we have a means to test any such binding. Signed-off-by:
-
Jonathan Cameron authored
Straight forward binding with vref optional for those part with internal regulators, but required for those without. Signed-off-by:
-
Jonathan Cameron authored
The use of vcc-supply for the reference voltage is unusual and should probably be deprecated as there is an explicit VREF pin on at least some of these parts. Signed-off-by:
-
Jonathan Cameron authored
Simple binding, with optional vref. Note that the Linux driver does support vcc-supply for historical reasons, but lets not let that get into any bindings that are checked going forwards. Hence I have deliberately not documented it. Signed-off-by:
-
Jonathan Cameron authored
The naming of the regulator is problematic. VCC is usually a supply voltage whereas these devices have a separate VREF pin. Secondly, the regulator core might have provided a stub regulator if a real regulator wasn't provided. That would in turn have failed to provide a voltage when queried. So reality was that there was no way to use the internal reference. In order to avoid breaking any dts out in the wild, make sure to fallback to the original vcc naming if vref is not available. Signed-off-by:
kernel test robot <lkp@intel.com> Acked-by:
-
- 17 Jul, 2021 8 commits
-
-
Jonathan Cameron authored
Binding for this high voltage DAC with temperature event signal. Signed-off-by:
-
Jonathan Cameron authored
Documenting existing binding, so little flexibility available. 2 channel devices that require separate reference voltages. Signed-off-by:
-
Jonathan Cameron authored
A simple binding for this particular DAC familly. Signed-off-by:
-
Jonathan Cameron authored
Bindings for the family of many channel DACs. Fairly straight forward with just a differing number of voltage references (an extra one for the 40 channel ad4371) Signed-off-by:
-
Jonathan Cameron authored
Note this is documenting bindings that have effectively existing ever since this driver was merged. The naming conventions for the ADI parts are inconsistent on the data sheets which has lead to a mixture of -X and -reference voltage part naming. We could attempt to clean this up, but as we are stuck supporting the existing binding it is probably not worthwhile. Signed-off-by:
-
Jonathan Cameron authored
This is documented what is currently the case. There are a number of things that could be added, but I don't feel the binding elements are obvious enough to document without a driver implementation to verify they are good choices. These include * Range * Regulators, both input and potentially output (if the loop being driven is ever described). I've listed Lars and myself as maintainers of the binding, but if anyone else wants to be added they would be most welcome! Signed-off-by:
-
Alexandru Ardelean authored
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by:
-
Alexandru Ardelean authored
This is another simple conversion to device-managed functions, requiring the use of devm_iio_device_register() and moving the disabling of the device on a devm_add_action_or_reset() hook. The i2c_set_clientdata() can be removed, as the PM functions can work with just the device object, to obtain the i2c_client object. Signed-off-by:
-
