- 07 Jul, 2020 3 commits
-
-
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 <alexandru.ardelean@analog.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
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:
Andy Shevchenko <andy.shevchenko@gmail.com> 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 13 commits
-
-
Keyur Patel authored
Fix typo: "tigger" --> "trigger" Signed-off-by:
Keyur Patel <iamkeyur96@gmail.com> Signed-off-by:
-
Lars-Peter Clausen authored
If a driver does not assign an of_node to a IIO device to IIO core will automatically assign the of_node of the parent device. This automatic assignment is done in the iio_device_register() function. There is a fair amount of drivers that currently manually assign the of_node of the IIO device. All but 4 of them can make use of the automatic assignment though. The exceptions are: * mxs-lradc-adc: Which uses the of_node of the parent of the parent. * stm32-dfsdm-adc, stm32-adc and stm32-dac: Which reference the of_node assigned to the IIO device before iio_device_register() is called. All other drivers are updated to use automatic assignment. This reduces the amount of boilerplate code involved in setting up the IIO device. The patch has mostly been auto-generated with the following semantic patch // <smpl> @exists@ expression indio_dev; expression parent; @@ indio_dev = \(devm_iio_device_alloc\|iio_device_alloc\)(&parent, ...) ... -indio_dev->dev.of_node = parent.of_node; @exists@ expression indio_dev; expression parent; @@ indio_dev = \(devm_iio_device_alloc\|iio_device_alloc\)(parent, ...) ... -indio_dev->dev.of_node = parent->of_node; // </smpl> Signed-off-by:
-
Alexandru Ardelean authored
These were found by doing some shell magic: ------------ for file in $(git grep -w devm_iio_device_alloc | cut -d: -f1 | sort | uniq) ; do if grep 'parent =' $file | grep -v trig | grep -vq devm_; then echo "$file -> $(grep "parent =" $file)" fi done ----------- The output is bearable [after the semantic patch is applied]. There is a mix of trigger assignments with some iio device parent assignments that are removed via this patch. JC: A few more added via inspection of all parent = statements in drivers/iio. Some of these may just have crossed with this series, others were less obvious to scripting due to some cross file / module boundary calls. Signed-off-by:
-
Alexandru Ardelean authored
This assignment is the more peculiar as it assigns the parent of the platform-device's device (i.e. pdev->dev.parent) as the IIO device's parent. Since the devm_iio_device_alloc() [now] assigns the device argument as the default parent (and since this is the more common case), for cases where the parent needs to be different, the iio_device_set_parent helper should be used. That makes things a bit more obvious about the new behavior of devm_iio_device_alloc() and makes it clearer that iio_device_set_parent() should be used. Signed-off-by:
-
Alexandru Ardelean authored
These were obtained by doing a 'git diff | grep \/\*', in the previous diff to find comments. These needed a bit more manual review, as the semantic patch isn't great for catching these. The result is: /* Initialize Counter device and driver data */ /* Initialize IIO device */ /* Establish that the iio_dev is a child of the spi device */ /* Estabilish that the iio_dev is a child of the spi device */ /* Initiate the Industrial I/O device */ /* Establish that the iio_dev is a child of the device */ - /* establish that the iio_dev is a child of the i2c device */ - /* establish that the iio_dev is a child of the i2c device */ /* This is only used for removal purposes */ /* setup the industrialio driver allocated elements */ /* variant specific configuration */ /* Setup for userspace synchronous on demand sampling. */ st->readback_delay_us += 5; /* Add tWAIT */ - /* Establish that the iio_dev is a child of the i2c device */ /* Establish that the iio_dev is a child of the i2c device */ Out of which, 4 are really left-over comments about parent assignment. 3 of them are removed by the semantic patch, as the comment removed (by spatch) would be for an empty line. Signed-off-by:
-
Alexandru Ardelean authored
This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by:
-
Alexandru Ardelean authored
By default, the device allocation will also assign a parent device to the IIO device object. In cases where devm_iio_device_alloc() is used, sometimes the parent device must be different than the device used to manage the allocation. In that case, this helper should be used to change the parent, hence the requirement to call this between allocation & registration. This pattern/requirement is not very common in the IIO space, and it may be cleaned up later. But until then, assigning the parent manually between allocation & registration is slightly easier. Signed-off-by:
-
Alexandru Ardelean authored
The change passes the parent device to the iio_device_alloc() call. This also updates the devm_iio_device_alloc() call to consider the device object as the parent device by default. Having it passed like this, should ensure that any IIO device object already has a device object as parent, allowing for neater control, like passing the 'indio_dev' object for other stuff [like buffers/triggers/etc], and potentially creating iiom_xxx(indio_dev) functions. With this patch, only the 'drivers/platform/x86/toshiba_acpi.c' needs an update to pass the parent object as a parameter. In the next patch all devm_iio_device_alloc() calls will be handled. Acked-by:
-
Chuhong Yuan authored
Since if there is no GPIO, nothing happens, replace devm_gpiod_get() with devm_gpiod_get_optional(). Also add IS_ERR() to fix the missing-check warning. Fixes: cee211f4 ("iio: amplifiers: ad8366: Add support for the ADA4961 DGA") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Acked-by:
-
Tomasz Duszynski authored
IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting raw concentrations of pollutants. Raw value should be meaningless before being properly scaled. Because of that description shouldn't mention raw value unit whatsoever. Fix this by rephrasing existing description so it follows conventions used throughout IIO ABI docs. Fixes: 8ff6b3bc ("iio: chemical: Add IIO_CONCENTRATION channel type") Signed-off-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
-
Alexandru Ardelean authored
Since changes can come from all sort of places, it may make sense to have this symbol as a dependency to make sure that the 'make allmodconfig' && 'make allyesconfig' build rules cover this driver as well for a compile-build/test. It seemed useful [recently] when trying to apply a change for this. Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
-
Jonathan Cameron authored
As this just calls dev_get_drvdata underneath which is happy with a const struct device * we should change and avoid potentially casting away a const in order to then put it back again. 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:
Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by:
-
