aboutsummaryrefslogtreecommitdiff
path: root/include/linux/iio
AgeCommit message (Collapse)AuthorFilesLines
2024-08-10iio: trigger: allow devices to suspend/resume theirs associated triggerDenis Benato1-0/+17
When a machine enters a sleep state while a trigger is associated to an iio device that trigger is not resumed after exiting the sleep state: provide iio device drivers a way to suspend and resume the associated trigger to solve the aforementioned bug. Each iio driver supporting external triggers is expected to call iio_device_suspend_triggering before suspending, and iio_device_resume_triggering upon resuming. Signed-off-by: Denis Benato <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-10iio: add child nodes support in iio backend frameworkOlivier Moysan1-0/+3
Add an API to support IIO generic channels binding: http://devicetree.org/schemas/iio/adc/adc.yaml# This new API is needed, as generic channel DT node isn't populated as a device. Add devm_iio_backend_fwnode_get() to allow an IIO device backend consumer to reference backend phandles in its child nodes. Signed-off-by: Olivier Moysan <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-10iio: add enable and disable services to iio backend frameworkOlivier Moysan1-0/+2
Add iio_backend_disable() and iio_backend_enable() APIs to allow IIO backend consumer to request backend disabling and enabling. Signed-off-by: Olivier Moysan <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-10iio: add read scale and offset services to iio backend frameworkOlivier Moysan1-1/+23
Add iio_backend_read_scale() and iio_backend_read_offset() services to read channel scale and offset from an IIO backbend device. Also add a read_raw callback which replicates the read_raw callback of the IIO framework, and is intended to request miscellaneous channel attributes from the backend device. Both scale and offset helpers use this callback. Signed-off-by: Olivier Moysan <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: add a modified prbs23 supportNuno Sa1-0/+2
Support ADI specific prb23 sequence that can be used both for calibrating or debugging digital interfaces. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240802-dev-iio-backend-add-debugfs-v2-3-4cb62852f0d0@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: add debugFs interfaceNuno Sa1-0/+14
This adds a basic debugfs interface for backends. Two new ops are being added: * debugfs_reg_access: Analogous to the core IIO one but for backend devices. * debugfs_print_chan_status: One useful usecase for this one is for testing test tones in a digital interface and "ask" the backend to dump more details on why a test tone might have errors. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240802-dev-iio-backend-add-debugfs-v2-2-4cb62852f0d0@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: introduce struct iio_backend_infoNuno Sa1-1/+11
Instead of only passing the backend ops when calling devm_iio_backend_register(), pass an info like structure that will contains the ops and additional information. Fow now, the backend name is being added as that will be used by the debugFS interface introduced in a later patch. It also opens the door for further customizations passed by backends. All users of devm_iio_backend_register() were updated accordingly. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240802-dev-iio-backend-add-debugfs-v2-1-4cb62852f0d0@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: core: add function to retrieve active_scan_mask indexJulien Stephan1-0/+2
Add a function to retrieve the index of the active scan mask inside the available scan masks array. As in iio_scan_mask_match and iio_sanity_check_avail_scan_masks, this function does not handle multi-long masks correctly. It only checks the first long to be zero, and will use such mask as a terminator even if there was bits set after the first long. This should be fine since the available_scan_mask has already been sanity tested using iio_sanity_check_avail_scan_masks. See iio_scan_mask_match and iio_sanity_check_avail_scan_masks for more details Signed-off-by: Julien Stephan <[email protected]> Reviewed-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20240731-ad7380-add-single-ended-chips-v2-2-cd63bf05744c@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: core: annotate masklength as __privateNuno Sa1-2/+2
Now that all users are using the proper accessors, we can mark masklength as __private so that no one tries to write. We also get help from checkers in warning us in case someone does it. To access the private field from IIO core code, we need to use the ACCESS_PRIVATE() macro. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240726-dev-iio-masklength-private3-v1-23-82913fc0fb87@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: spelling: continuous -> continuousDavid Lechner1-1/+1
This fixes the spelling in IIO_BACKEND_INTERNAL_CONTINUOUS_WAVE. Signed-off-by: David Lechner <[email protected]> Link: https://patch.msgid.link/20240726-iio-backend-spelling-continuous-v1-1-467c6e3f78ff@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-08-03iio: backend: remove unused parameterNuno Sa1-2/+1
Indio_dev was not being used in iio_backend_extend_chan_spec() so remove it. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/20240709-dev-iio-backend-add-debugfs-v1-1-fb4b8f2373c7@analog.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-07-29iio: core: add accessors 'masklength'Nuno Sa1-0/+18
'masklength' is supposed to be an IIO private member. However, drivers (often in trigger handlers) need to access it to iterate over the enabled channels for example (there are other reasons). Hence, a couple of new accessors are being added: * iio_for_each_active_channel() - Iterates over the active channels; * iio_get_masklength() - Get length of the channels mask. The goal of these new accessors is to annotate 'masklength' as private as soon as all drivers accessing it are converted to use the new helpers. Signed-off-by: Nuno Sa <[email protected]> Reviewed-by: Alexandru Ardelean <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-30iio: buffer-dma: Enable support for DMABUFsPaul Cercueil1-0/+31
Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf() and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO DMA buffer implementations. Signed-off-by: Paul Cercueil <[email protected]> Co-developed-by: Nuno Sa <[email protected]> Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-30iio: core: Add new DMABUF interface infrastructurePaul Cercueil1-0/+33
Add the necessary infrastructure to the IIO core to support a new optional DMABUF based interface. With this new interface, DMABUF objects (externally created) can be attached to a IIO buffer, and subsequently used for data transfer. A userspace application can then use this interface to share DMABUF objects between several interfaces, allowing it to transfer data in a zero-copy fashion, for instance between IIO and the USB stack. The userspace application can also memory-map the DMABUF objects, and access the sample data directly. The advantage of doing this vs. the read() interface is that it avoids an extra copy of the data between the kernel and userspace. This is particularly userful for high-speed devices which produce several megabytes or even gigabytes of data per second. As part of the interface, 3 new IOCTLs have been added: IIO_BUFFER_DMABUF_ATTACH_IOCTL(int fd): Attach the DMABUF object identified by the given file descriptor to the buffer. IIO_BUFFER_DMABUF_DETACH_IOCTL(int fd): Detach the DMABUF object identified by the given file descriptor from the buffer. Note that closing the IIO buffer's file descriptor will automatically detach all previously attached DMABUF objects. IIO_BUFFER_DMABUF_ENQUEUE_IOCTL(struct iio_dmabuf *): Request a data transfer to/from the given DMABUF object. Its file descriptor, as well as the transfer size and flags are provided in the "iio_dmabuf" structure. These three IOCTLs have to be performed on the IIO buffer's file descriptor, obtained using the IIO_BUFFER_GET_FD_IOCTL() ioctl. Signed-off-by: Paul Cercueil <[email protected]> Co-developed-by: Nuno Sa <[email protected]> Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-28iio: Add iio_read_channel_label to inkern APISean Anderson1-0/+10
It can be convenient for other in-kernel drivers to reuse IIO channel labels. Export the iio_read_channel_label function to allow this. The signature is different depending on where we are calling it from, so the meat is moved to do_iio_read_channel_label. Signed-off-by: Sean Anderson <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-25iio: imu: adis: remove legacy lock helpersNuno Sa1-10/+0
Since all users were converted to the new cleanup based helper, adis_dev_lock() and adis_dev_unlock() can now be removed from the lib. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-25iio: imu: adis: add cleanup based lock helpersNuno Sa1-0/+4
Add two new lock helpers that make use of the cleanup guard() and scoped_guard() macros. Thus, users won't have to worry about unlocking which is less prone to errors and allows for simpler error paths. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-25iio: imu: adis: move to the cleanup magicNuno Sa1-41/+13
This makes locking and handling error paths simpler. Signed-off-by: Nuno Sa <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-25iio: adc: ad_sigma_delta: add disable_one callbackDumitru Ceclan1-0/+14
Sigma delta ADCs with a sequencer need to disable the previously enabled channel when reading using ad_sigma_delta_single_conversion(). This was done manually in drivers for devices with sequencers. This patch implements handling of single channel disabling after a single conversion. Reviewed-by: Nuno Sa <[email protected]> Signed-off-by: Dumitru Ceclan <[email protected]> Reviewed-by: David Lechner <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-04iio: imu: adis_trigger: Allow level interrupts for FIFO readingsRamona Gradinariu1-0/+1
Currently, adis library allows configuration only for edge interrupts, needed for data ready sampling. This patch removes the restriction for level interrupts for devices which have FIFO support. Furthermore, in case of devices which have FIFO support, devm_request_threaded_irq is used for interrupt allocation, to avoid flooding the processor with the FIFO watermark level interrupt, which is active until enough data has been read from the FIFO. Reviewed-by: Nuno Sa <[email protected]> Signed-off-by: Ramona Gradinariu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-04iio: imu: adis_buffer: Add buffer setup API with buffer attributesRamona Gradinariu1-4/+16
Add new API called devm_adis_setup_buffer_and_trigger_with_attrs() which also takes buffer attributes as a parameter. Rewrite devm_adis_setup_buffer_and_trigger() implementation such that it calls devm_adis_setup_buffer_and_trigger_with_attrs() with buffer attributes parameter NULL Reviewed-by: Nuno Sa <[email protected]> Signed-off-by: Ramona Gradinariu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-04iio: add support for multiple scan types per channelDavid Lechner1-2/+53
This adds new fields to the iio_channel structure to support multiple scan types per channel. This is useful for devices that support multiple resolution modes or other modes that require different data formats of the raw data. To make use of this, drivers need to implement the new callback get_current_scan_type() to resolve the scan type for a given channel based on the current state of the driver. There is a new scan_type_ext field in the iio_channel structure that should be used to store the scan types for any channel that has more than one. There is also a new flag has_ext_scan_type that acts as a type discriminator for the scan_type/ext_scan_type union. A union is used so that we don't grow the size of the iio_channel structure and also makes it clear that scan_type and ext_scan_type are mutually exclusive. The buffer code is the only code in the IIO core code that is using the scan_type field. This patch updates the buffer code to use the new iio_channel_validate_scan_type() function to ensure it is returning the correct scan type for the current state of the device when reading the sysfs attributes. The buffer validation code is also update to validate any additional scan types that are set in the scan_type_ext field. Part of that code is refactored to a new function to avoid duplication. Some userspace tools may need to be updated to re-read the scan type after writing any other attribute. During testing, we noticed that we had to restart iiod to get it to re-read the scan type after enabling oversampling on the ad7380 driver. Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/20240530-iio-add-support-for-multiple-scan-types-v3-3-cbc4acea2cfa@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-06-04iio: introduce struct iio_scan_typeDavid Lechner1-19/+22
This gives the channel scan_type a named type so that it can be used to simplify code in later commits. Signed-off-by: David Lechner <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/20240530-iio-add-support-for-multiple-scan-types-v3-1-cbc4acea2cfa@baylibre.com Signed-off-by: Jonathan Cameron <[email protected]>
2024-05-03iio: invensense: fix timestamp glitches when switching frequencyJean-Baptiste Maneyrol1-2/+1
When a sensor is running and there is a FIFO frequency change due to another sensor turned on/off, there are glitches on timestamp. Fix that by using only interrupt timestamp when there is the corresponding sensor data in the FIFO. Delete FIFO period handling and simplify internal functions. Update integration inside inv_mpu6050 and inv_icm42600 drivers. Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic") Cc: [email protected] Signed-off-by: Jean-Baptiste Maneyrol <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-29iio: backend: add API for interface tuningNuno Sa1-0/+36
This is in preparation for supporting interface tuning in one for the devices using the axi-adc backend. The new added interfaces are all needed for that calibration: * iio_backend_test_pattern_set(); * iio_backend_chan_status(); * iio_backend_iodelay_set(); * iio_backend_data_sample_trigger(). Interface tuning is the process of going through a set of known points (typically by the frontend), change some clk or data delays (or both) and send/receive some known signal (so called test patterns in this change). The receiving end (either frontend or the backend) is responsible for validating the signal and see if it's good or not. The goal for all of this is to come up with ideal delays at the data interface level so we can have a proper, more reliable data transfer. Also note that for some devices we can change the sampling rate (which typically means changing some reference clock) and that can affect the data interface. In that case, it's import to run the tuning algorithm again as the values we had before may no longer be the best (or even valid) ones. Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-29iio: backend: change docs paddingNuno Sa1-19/+19
Using tabs and maintaining the start of the docs aligned is a pain and may lead to lot's of unrelated changes when adding new members. Hence, let#s change things now and just have a simple space after the member name. Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-29iio: core: Add iio_read_acpi_mount_matrix() helper functionHans de Goede1-0/+13
The ACPI "ROTM" rotation matrix parsing code atm is already duplicated between bmc150-accel-core.c and kxcjk-1013.c and a third user of this is coming. Add an iio_read_acpi_mount_matrix() helper function for this. The 2 existing copies of the code are identical, except that the kxcjk-1013.c has slightly better error logging. To new helper is a 1:1 copy of the kxcjk-1013.c version, the only change is the addition of a "char *acpi_method" parameter since some bmc150 dual-accel setups (360° hinges with 1 accel in kbd/base + 1 in display) declare both accels in a single ACPI device with 2 different method names for the 2 matrices. This new acpi_method parameter is not "const char *" because the pathname parameter to acpi_evaluate_object() is not const. The 2 existing copies of this function will be removed in further patches in this series. Acked-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-20iio: backend: add new functionalityNuno Sa1-0/+49
This adds the needed backend ops for supporting a backend inerfacing with an high speed dac. The new ops are: * data_source_set(); * set_sampling_freq(); * extend_chan_spec(); * ext_info_set(); * ext_info_get(). Also to note the new helpers that are meant to be used by the backends when extending an IIO channel (adding extended info): * iio_backend_ext_info_set(); * iio_backend_ext_info_get(). Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-20iio: buffer-dmaengine: Support specifying buffer directionPaul Cercueil1-6/+19
Update the devm_iio_dmaengine_buffer_setup() function to support specifying the buffer direction. Update the iio_dmaengine_buffer_submit() function to handle input buffers as well as output buffers. Signed-off-by: Paul Cercueil <[email protected]> Reviewed-by: Alexandru Ardelean <[email protected]> Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-20iio: buffer-dma: Enable buffer write supportPaul Cercueil1-0/+2
Adding write support to the buffer-dma code is easy - the write() function basically needs to do the exact same thing as the read() function: dequeue a block, read or write the data, enqueue the block when entirely processed. Therefore, the iio_buffer_dma_read() and the new iio_buffer_dma_write() now both call a function iio_buffer_dma_io(), which will perform this task. Note that we preemptively reset block->bytes_used to the buffer's size in iio_dma_buffer_request_update(), as in the future the iio_dma_buffer_enqueue() function won't reset it. Signed-off-by: Paul Cercueil <[email protected]> Reviewed-by: Alexandru Ardelean <[email protected]> Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-20iio: buffer-dma: Rename iio_dma_buffer_data_available()Paul Cercueil1-1/+1
Change its name to iio_dma_buffer_usage(), as this function can be used both for the .data_available and the .space_available callbacks. Signed-off-by: Paul Cercueil <[email protected]> Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-04-20iio: buffer-dma: add iio_dmaengine_buffer_setup()Nuno Sa1-2/+3
This brings the DMA buffer API more in line with what we have in the triggered buffer. There's no need of having both devm_iio_dmaengine_buffer_setup() and devm_iio_dmaengine_buffer_alloc(). Hence we introduce the new iio_dmaengine_buffer_setup() that together with devm_iio_dmaengine_buffer_setup() should be all we need. Note that as part of this change iio_dmaengine_buffer_alloc() is again static and the axi-adc was updated accordingly. Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-03-25iio: adc: ad_sigma_delta: Add optional irq selectionDumitru Ceclan1-0/+3
Add optional irq_num attribute to ad_sigma_delta_info structure for selecting the used interrupt line for ADC's conversion completion. Signed-off-by: Dumitru Ceclan <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-02-25Merge tag 'iio-for-6.9a' of ↵Greg Kroah-Hartman4-69/+104
http://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: IIO: 1st set of new device support, features and cleanup for 6.9 IIO Backend support =================== New approach from Nuno Sa to the problem of reuse of drivers with IIO devices that are actually the combination of a highspeed chip and an FPGA core handling the data capture and flows. It will hopefully also apply to some other split designs. The ad9467 and axi-adi drivers are converted over to this framework. New device support ================== adi,admfm2000 - New driver for this dual microwave down converter. ams,as73211 - Add support for as7331 UV sensor. richtek,rtq6056 - Add support for related parts RTQ6053 and RTQ6059 st,lsm6dsx - Add ASM330LHHXG1 accelerometer and gyro support (mainly IDs) ti,ads1298 - New driver for this medical ADC. Features ======== tests - Unit tests for the gain-time-scale helper library. bosch,bmi088 - I2C support. bosh,bmi160 - Add 10EC5280 ACPI ID. Used in a number of devices that won't get fixed. The ID is actually a PCI ID belonging to realtech. No response was received to earlier attempts to notify them of this. The manufacturers of some devices have replied to say they will not fix this incorrect ID. Add the ID and hope it isn't a problem. bosch,bmi323 - Add BOSC0200 ACPI ID. Note this is a duplicate of one in the bmc150 driver (it appears these parts share a windows driver). Both drivers perform an ID check that is safe on the other part before successfully probing. hid-sensors-als - Add color temperature and chromaticity support. Note this is a replacement for the series reverted in 6.8 that correctly handles all the potential channel combinations. honeywell,hsc030pa - Triggered buffer support (after driver cleanup). honeywell,mprls00025pa - Improved error handling. - New DT binding to allow use of part number triplet as provided in data sheet to specify equivalent of most of the binding more efficiently. - SPI support. memsic,mxc4005 - ACPI ID MDA6655 as seen in the Chuwi Minibook X 2023 ti,hdc3020 - Add threshold event support (after some driver cleanup) veml,vcnl4000 - Switch to high resolution proximity measurement. Cleanup ======= Various minor typo fixes and better use of defines etc. Treewide - Stop using ACPI_PTR(). The savings in space are small and not worth the complexity of __maybe_unused of ifdef guards. To avoid use in new IIO drivers based on copy and paste, clean it out. - cleanup.h based handling of iio_device_claim_direct_mode()/ iio_device_release_direct_mode() using scope_cond_guard(). In many drivers this is combined with other automated cleanup to give maximum simplifications. An initial set of drivers are converted over to this infrastructure. Tools - Use rewinddir() instead of seekdir() to return to start of file. core - Make iio_bus_type constant. adi,ad16475 - Use irq_get_trigger_type() instead of opencoding. adi,ad16480 - Use irq_get_trigger_type() instead of opencoding. adi,ad-sigma-delta - Avoid overwriting IRQ flags if provided by firmware. ams,as73211 - Use IIO_VAL_FRACTIONAL for scales to simplify the code and potentially improve accuracy. gts-library - Use a div64_u64() instead of a loop to do a division. honeywell,mprls00025pa - Clean up dt-binding doc. - Drop defaults when DT binding not providing values. Very unlikely these were useful given they were wrong for vast majority of supported devices. - Whitespace cleanup miramems,da280 - Use i2c_get_match_data() to replace hand rolled ACPI matching code. semtech,sx9324 - Avoid unnecessary copying of property strings. st,lsm6dsx - Improve docs, particularly wrt to making addition of new device support less noisy. st,lsm9ds0 - Use dev_err_probe() in all probe() error handling. - Improved header includes. - Tidy up termination of ID tables. ti,ads1014 - Correct upper bound on PGA (wrong value had no actual impact) ti,afe4403/4404 - devm_ useage to simplify error handling in probe() and allow() remove to be dropped. voltage-divider - Add dt-binding for io-channel-cells to allow such a device to be both an IIO consumer and IIO producer at the same time. * tag 'iio-for-6.9a' of http://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (106 commits) iio: imu: bmi323: Add ACPI Match Table iio: accel: bmc150: Document duplicate ACPI entries with bmi323 driver iio: adc: ti-ads1298: Add driver dt-bindings: iio: adc: ti-ads1298: Add bindings iio: pressure: hsc030pa add triggered buffer iio: pressure: hsc030pa add mandatory delay iio: pressure: hsc030pa: update datasheet URLs iio: pressure: hsc030pa: include cleanup iio: pressure: hsc030pa: use signed type to hold div_64() result dt-bindings: iio: pressure: honeywell,hsc030pa.yaml add spi props iio: st_sensors: lsm9ds0: Use common style for terminator in ID tables iio: st_sensors: lsm9ds0: Don't use "proxy" headers iio: st_sensors: lsm9ds0: Use dev_err_probe() everywhere iio: adc: adi-axi-adc: move to backend framework iio: adc: ad9467: convert to backend framework iio: add the IIO backend framework iio: buffer-dmaengine: export buffer alloc and free functions of: property: add device link support for io-backends dt-bindings: adc: axi-adc: update bindings for backend framework dt-bindings: adc: ad9467: add new io-backend property ...
2024-02-19iio: adc: adi-axi-adc: move to backend frameworkNuno Sa1-68/+0
Move to the IIO backend framework. Devices supported by adi-axi-adc now register themselves as backend devices. Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2024-02-19iio: add the IIO backend frameworkNuno Sa1-0/+72
This is a Framework to handle complex IIO aggregate devices. The typical architecture is to have one device as the frontend device which can be "linked" against one or multiple backend devices. All the IIO and userspace interface is expected to be registers/managed by the frontend device which will callback into the backends when needed (to get/set some configuration that it does not directly control). The basic framework interface is pretty simple: - Backends should register themselves with @devm_iio_backend_register() - Frontend devices should get backends with @devm_iio_backend_get() Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2024-02-19iio: buffer-dmaengine: export buffer alloc and free functionsNuno Sa1-0/+3
Export iio_dmaengine_buffer_free() and iio_dmaengine_buffer_alloc(). This is in preparation of introducing IIO backends support. This will allow us to allocate a buffer and control it's lifetime from a device different from the one holding the DMA firmware properties. Effectively, in this case the struct device holding the firmware information about the DMA channels is not the same as iio_dev->dev.parent (typical case). While at it, namespace the buffer-dmaengine exports and update the current user of these buffers. Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2024-02-17iio: core: make iio_bus_type constRicardo B. Marliere1-1/+1
Now that the driver core can properly handle constant struct bus_type, move the iio_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <[email protected]> Suggested-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Ricardo B. Marliere <[email protected]> Acked-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-02-17iio: locking: introduce __cleanup() based direct mode claiming infrastructureJonathan Cameron1-0/+28
Allows use of: iio_device_claim_direct_scoped(return -EBUSY, indio_dev) { } to automatically call iio_device_release_direct_mode() based on scope. Typically seen in combination with local device specific locks which are already have automated cleanup options via guard(mutex)(&st->lock) and scoped_guard(). Using both together allows most error handling to be automated. Reviewed-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-02-04iio: commom: st_sensors: ensure proper DMA alignmentNuno Sa1-2/+2
Aligning the buffer to the L1 cache is not sufficient in some platforms as they might have larger cacheline sizes for caches after L1 and thus, we can't guarantee DMA safety. That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same for st_sensors common buffer. While at it, moved the odr_lock before buffer_data as we definitely don't want any other data to share a cacheline with the buffer. [1]: https://lore.kernel.org/linux-iio/[email protected]/ Fixes: e031d5f558f1 ("iio:st_sensors: remove buffer allocation at each buffer enable") Signed-off-by: Nuno Sa <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2024-01-22iio: adc: ad_sigma_delta: ensure proper DMA alignmentNuno Sa1-1/+3
Aligning the buffer to the L1 cache is not sufficient in some platforms as they might have larger cacheline sizes for caches after L1 and thus, we can't guarantee DMA safety. That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same for the sigma_delta ADCs. [1]: https://lore.kernel.org/linux-iio/[email protected]/ Fixes: 0fb6ee8d0b5e ("iio: ad_sigma_delta: Don't put SPI transfer buffer on the stack") Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/20240117-dev_sigma_delta_no_irq_flags-v1-1-db39261592cf@analog.com Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2024-01-22iio: imu: adis: ensure proper DMA alignmentNuno Sa1-1/+2
Aligning the buffer to the L1 cache is not sufficient in some platforms as they might have larger cacheline sizes for caches after L1 and thus, we can't guarantee DMA safety. That was the whole reason to introduce IIO_DMA_MINALIGN in [1]. Do the same for the sigma_delta ADCs. [1]: https://lore.kernel.org/linux-iio/[email protected]/ Fixes: ccd2b52f4ac6 ("staging:iio: Add common ADIS library") Signed-off-by: Nuno Sa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2023-12-26iio: linux/iio.h: fix Excess kernel-doc description warningRandy Dunlap1-6/+0
Remove the @of_xlate: lines to prevent the kernel-doc warning: include/linux/iio/iio.h:534: warning: Excess struct member 'of_xlate' description in 'iio_info' Signed-off-by: Randy Dunlap <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2023-12-21iio: buffer-dma: Get rid of outgoing queuePaul Cercueil1-4/+3
The buffer-dma code was using two queues, incoming and outgoing, to manage the state of the blocks in use. While this totally works, it adds some complexity to the code, especially since the code only manages 2 blocks. It is much easier to just check each block's state manually, and keep a counter for the next block to dequeue. Since the new DMABUF based API wouldn't use the outgoing queue anyway, getting rid of it now makes the upcoming changes simpler. With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can be removed. Signed-off-by: Paul Cercueil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2023-12-11iio: core: introduce trough info element for minimum valuesJavier Carrasco1-0/+1
The IIO_CHAN_INFO_PEAK info element is used for maximum values and currently there is no equivalent for minimum values. Instead of overloading the existing peak info element, a new info element can be added. In principle there is no need to add a _TROUGH_SCALE element as the scale will be the same as the one required for INFO_PEAK, which in turn is sometimes omitted if a single scale for peaks and raw values is required. Add an IIO_CHAN_INFO_TROUGH info element for minimum values. Signed-off-by: Javier Carrasco <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2023-12-10iio: adc: ad9467: fix scale settingNuno Sa1-0/+4
When reading in_voltage_scale we can get something like: root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale 0.038146 However, when reading the available options: root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale_available 2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010 which does not make sense. Moreover, when trying to set a new scale we get an error because there's no call to __ad9467_get_scale() to give us values as given when reading in_voltage_scale. Fix it by computing the available scales during probe and properly pass the list when .read_available() is called. While at it, change to use .read_available() from iio_info. Also note that to properly fix this, adi-axi-adc.c has to be changed accordingly. Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by: Nuno Sa <[email protected]> Reviewed-by: David Lechner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2023-10-11iio: event: add optional event label supportDavid Lechner1-0/+8
This adds a new optional field to struct iio_info to allow drivers to specify a label for the event. This is useful for cases where there are many events or the event attribute name is not descriptive enough or where an event doesn't have any other attributes. The implementation is based on the existing label support for channels. So either all events of a device have a label attribute or none do. Signed-off-by: David Lechner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2023-10-05iio: improve doc for available_scan_maskMatti Vaittinen1-1/+3
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: Matti Vaittinen <[email protected]> Link: https://lore.kernel.org/r/4e43bf0186df5c8a56b470318b4827605f9cad6c.1695727471.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <[email protected]>
2023-09-12iio: Remove unused declarationsYue Haibing2-6/+0
Commit 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs") declared but never implemented iio_sw_device_type_configfs_{un}register(). Commit b662f809d410 ("iio: core: Introduce IIO software triggers") declared but never implemented iio_sw_trigger_type_configfs_{un}register(). Commit a3e0b51884ee ("iio: accel: add support for FXLS8962AF/FXLS8964AF accelerometers") declared but never implemented fxls8962af_core_remove(). Commit 8dedcc3eee3a ("iio: core: centralize ioctl() calls to the main chardev") declared but never implemented iio_device_ioctl(). Commit d430f3c36ca6 ("iio: imu: inv_mpu6050: Use regmap instead of i2c specific functions") removed inv_mpu6050_write_reg() but not its declaration. Signed-off-by: Yue Haibing <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2023-09-01Merge tag 'char-misc-6.6-rc1' of ↵Linus Torvalds2-0/+97
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver updates from Greg KH: "Here is the big set of char/misc and other small driver subsystem changes for 6.6-rc1. Stuff all over the place here, lots of driver updates and changes and new additions. Short summary is: - new IIO drivers and updates - Interconnect driver updates - fpga driver updates and additions - fsi driver updates - mei driver updates - coresight driver updates - nvmem driver updates - counter driver updates - lots of smaller misc and char driver updates and additions All of these have been in linux-next for a long time with no reported problems" * tag 'char-misc-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (267 commits) nvmem: core: Notify when a new layout is registered nvmem: core: Do not open-code existing functions nvmem: core: Return NULL when no nvmem layout is found nvmem: core: Create all cells before adding the nvmem device nvmem: u-boot-env:: Replace zero-length array with DECLARE_FLEX_ARRAY() helper nvmem: sec-qfprom: Add Qualcomm secure QFPROM support dt-bindings: nvmem: sec-qfprom: Add bindings for secure qfprom dt-bindings: nvmem: Add compatible for QCM2290 nvmem: Kconfig: Fix typo "drive" -> "driver" nvmem: Explicitly include correct DT includes nvmem: add new NXP QorIQ eFuse driver dt-bindings: nvmem: Add t1023-sfp efuse support dt-bindings: nvmem: qfprom: Add compatible for MSM8226 nvmem: uniphier: Use devm_platform_get_and_ioremap_resource() nvmem: qfprom: do some cleanup nvmem: stm32-romem: Use devm_platform_get_and_ioremap_resource() nvmem: rockchip-efuse: Use devm_platform_get_and_ioremap_resource() nvmem: meson-mx-efuse: Convert to devm_platform_ioremap_resource() nvmem: lpc18xx_otp: Convert to devm_platform_ioremap_resource() nvmem: brcm_nvram: Use devm_platform_get_and_ioremap_resource() ...
Powered by cgit, Gruvboxed by Blaster4385.