- 07 Jul, 2020 15 commits
-
-
Jonathan Cameron authored
Allows use of ACPI with PRP0001 and is generally something we are trying to avoid having people cut and paste into new drivers without thinking about it. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Vladimir Barinov <vladimir.barinov@cogentembedded.com> Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com>
-
Jonathan Cameron authored
I guess this is a left over from some earlier cleanup. Not used currently. Signed-off-by:
-
Jonathan Cameron authored
Whilst is unlikely anyone will be using this part with an ACPI PRP0001 based binding any time soon, we are getting a lot of cut and pasting of this pattern so I am looking to remove it entirely from IIO. In this case CONFIG_OF protections also removed and mod_devicetable.h include added given direct use of struct of_device_id. Signed-off-by:
-
Krzysztof Kozlowski authored
The compatible for BMM150 should not have "_magn" suffix because, unlike two other Bosch devices, it is only a magnetometer. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
The driver supports also BMC156B and BMM150B. Add existing compatibles marking the BMM150B one as deprecated (due to redundant suffix "_magn" because the device unlike two others is a magnetometer only). Introduce a new, proper compatible for the deprecated one. Signed-off-by:
-
Nuno Sá authored
The value retrieved by `irqd_get_trigger_type()` is not an irq flag. While the values are the same, the meaning is different. Signed-off-by:
Nuno Sá <nuno.sa@analog.com> Signed-off-by:
-
Randy Dunlap authored
Drop the doubled word "struct". Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: William Breathitt Gray <vilhelm.gray@gmail.com> Cc: linux-iio@vger.kernel.org Signed-off-by:
-
Randy Dunlap authored
Drop the doubled word "the". Signed-off-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
-
Alexandru Ardelean authored
Same as with other private fields, this moves the event interface reference to the opaque IIO device object, to be invisible to drivers. Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Alexandru Ardelean authored
This change moves the 'buffer_list' away from the public IIO device object into the private part. Signed-off-by:
-
Alexandru Ardelean authored
This change bit straightforward and simple, since the 'channel_attr_list' & 'chan_attr_group' fields are only used in 'industrialio-core.c'. This change moves to the private IIO device object Signed-off-by:
-
Alexandru Ardelean authored
This change moves all iio_dev debugfs fields to the iio_dev_priv object. It's not the biggest advantage yet (to the whole thing of abstractization) but it's a start. The iio_get_debugfs_dentry() function (which is moved in industrialio-core.c) needs to also be guarded against the CONFIG_DEBUG_FS symbol, when it isn't defined. We do want to keep the inline definition in the iio.h header, so that the compiler can better infer when to compile out debugfs code that is related to the IIO debugfs directory. Signed-off-by:
-
Alexandru Ardelean authored
There was a recent discussion about this code: https://lore.kernel.org/linux-iio/20200322165317.0b1f0674@archlinux/ This looks like a good time to removed this, since any issues about it should pop-up under testing, because the iio_dev is having a bit of an overhaul and stuff being moved to iio_dev_opaque. Signed-off-by:
-
Alexandru Ardelean authored
There are plenty of bad designs we want to discourage or not have to review manually usually about accessing private (marked as [INTERN]) fields of 'struct iio_dev'. Sometimes users copy drivers that are not always the best examples. A better idea is to hide those fields into the framework. For 'struct iio_dev' this is a 'struct iio_dev_opaque' which wraps a public 'struct iio_dev' object. In the next series, some fields will be moved to this new struct, each with it's own rework. This rework will not be complete-able for a while, as many fields need some drivers to be reworked in order to finalize them (e.g. 'indio_dev->mlock'). But some fields can already be moved, and in time, all of them may get there (in the 'struct iio_dev_opaque' object). Since a lot of drivers also call 'iio_priv()', in order to preserve fast-paths (where this matters), the public iio_dev object will have a 'priv' field that will have the pointer to the private information already computed. The reference returned by this field should be guaranteed to be cacheline aligned. The opaque parts will be moved into the 'include/linux/iio/iio-opaque.h' header. Should the hidden information be required for some debugging or some special needs, it can be made available via this header. Otherwise, only the IIO core files should include this file. Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information, and also keeping a reference to the iio device for some quirky paths. One [quirky] path is the at91_adc_workq_handler() which requires the IIO device & the state struct to push to buffers. Since this requires the back-ref to the IIO device, the at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The information required in this function is mostly for debugging purposes. Replacing it with a reference to the IIO device would have been a slightly bigger change, which may not be worth it (for just the debugging purpose and given that we need the back-ref to the IIO device anyway). Signed-off-by:
-
- 27 Jun, 2020 21 commits
-
-
Tomasz Duszynski authored
Add SCD30 sensor binding file. Signed-off-by:
Tomasz Duszynski <tomasz.duszynski@octakon.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Tomasz Duszynski authored
Add serial interface driver for the SCD30 sensor. Signed-off-by:
-
Tomasz Duszynski authored
Add I2C interface driver for the SCD30 sensor. Signed-off-by:
-
Tomasz Duszynski authored
Add Sensirion SCD30 carbon dioxide core driver. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add MAINTAINERS entry for InvenSense ICM-426xx IMU device. Signed-off-by:
Jean-Baptiste Maneyrol <jmaneyrol@invensense.com> Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Document the ICM-426xxx devices devicetree bindings. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add a timestamping mechanism for buffer that provides accurate event timestamps when using watermark. This mechanism estimates device internal clock by comparing FIFO interrupts delta time and device elapsed time computed by parsing FIFO data. Take interrupt timestamp in hard irq handler and add IIO device specific timestamp structures in device private allocation. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add all FIFO parsing and reading functions. Add accel and gyro kfifo buffer and FIFO data parsing. Use device interrupt for reading data FIFO and launching accel and gyro parsing. Support hwfifo watermark by multiplexing gyro and accel settings. Support hwfifo flush. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add INT1 interrupt support. Support interrupt edge and level, active high or low. Push-pull or open-drain configurations. Interrupt will be used to read data from the FIFO. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Hardware offset available as calibscale sysfs attributes are real physical values exprimed in SI units. calibscale_available sysfs attributes represents the range of acceptable values. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add 3 modules: inv-icm42600, inv-icm42600-i2c, inv-icm42600-spi. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add temperature channel in gyroscope and accelerometer devices. Temperature is available in full 16 bits resolution when reading register and in low 8 bits resolution in the FIFO. Return full precision raw temperature with corresponding scale and offset. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add IIO device for accelerometer sensor with data polling interface. Attributes: raw, scale, sampling_frequency, calibbias. Accelerometer in low noise mode. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add IIO device for gyroscope sensor with data polling interface. Attributes: raw, scale, sampling_frequency, calibbias. Gyroscope in low noise mode. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add SPI driver for InvenSense ICM-426xxx devices. Configure bus signal slew rates as indicated in the datasheet. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Add I2C driver for InvenSense ICM-426xxx devices. Configure bus signal slew rates as indicated in the datasheet. Signed-off-by:
-
Jean-Baptiste Maneyrol authored
Core component of a new driver for InvenSense ICM-426xx devices. It includes registers definition, main probe/setup, and device utility functions. ICM-426xx devices are latest generation of 6-axis IMU, gyroscope+accelerometer and temperature sensor. This device includes a 2K FIFO, supports I2C/I3C/SPI, and provides intelligent motion features like pedometer, tilt detection, and tap detection. Signed-off-by:
-
Jishnu Prakash authored
Add a common function used for read_raw callback for both PMIC5 and PMIC7 ADCs. Signed-off-by:
Jishnu Prakash <jprakash@codeaurora.org> Signed-off-by:
-
Simon Xue authored
Add the ability to also support access via (triggered) buffers next to the existing direct mode. Device in question is the Odroid Go Advance that connects a joystick to two of the saradc channels for X and Y axis and the new (and still pending) adc joystick driver of course wants to use triggered buffers from the iio subsystem. Signed-off-by:
Simon Xue <xxm@rock-chips.com> [some simplifications and added commit description] Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Signed-off-by:
-
Heiko Stuebner authored
As suggested give the current ADC_CHANNEL constant a distinct and consistent prefix. Suggested-by:
Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by:
-
Heiko Stuebner authored
Parts of the saradc probe rely on devm functions and later parts do not. This makes it more difficult to for example enable triggers via their devm-functions and would need more undo-work in remove. So to make life easier for the driver, move the rest of probe calls also to their devm-equivalents. This includes moving the clk- and regulator-disabling to a devm_action so that they gets disabled both during remove and in the error case in probe, after the action is registered. Signed-off-by:
-
- 20 Jun, 2020 3 commits
-
-
Lars-Peter Clausen authored
All devices using a triggered buffer need to attach and detach the trigger to the device in order to properly work. Instead of doing this in each and every driver by hand move this into the core. At this point in time, all drivers should have been resolved to attach/detach the poll-function in the same order. This patch removes all explicit calls of iio_triggered_buffer_postenable() & iio_triggered_buffer_predisable() in all drivers, since the core handles now the pollfunc attach/detach. The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's not immediately obvious that removing the hooks doesn't break anything. Eugen was able to test on at91-sama5d2-adc driver, sama5d2-xplained board. All seems to be fine. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information. Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
-
Alexandru Ardelean authored
We may want to get rid of the iio_priv_to_dev() helper. The reason is that we will hide some of the members of the iio_dev structure (to prevent drivers from accessing them directly), and that will also mean hiding the implementation of the iio_priv_to_dev() helper inside the IIO core. Hiding the implementation of iio_priv_to_dev() implies that some fast-paths may not be fast anymore, so a general idea is to try to get rid of the iio_priv_to_dev() altogether. The iio_priv() helper won't be affected by the rework, as the iio_dev struct will keep a reference to the private information. For this driver, not using iio_priv_to_dev(), means reworking some paths to pass the iio device and using iio_priv() to access the private information. Signed-off-by:
-
- 14 Jun, 2020 1 commit
-
-
Keyur Patel authored
Fix typo: "tigger" --> "trigger" Signed-off-by:
Keyur Patel <iamkeyur96@gmail.com> Signed-off-by:
-
