summaryrefslogtreecommitdiffstats
path: root/include/linux/iio
Commit message (Collapse)AuthorAgeFilesLines
* iio: sw-device: Fix config group initializationLars-Peter Clausen2017-03-131-1/+1
| | | | | | | | | | | | | | | | | | Use the IS_ENABLED() helper macro to ensure that the configfs group is initialized either when configfs is built-in or when configfs is built as a module. Otherwise software device creation will result in undefined behaviour when configfs is built as a module since the configfs group for the device not properly initialized. Similar to commit b2f0c09664b7 ("iio: sw-trigger: Fix config group initialization"). Fixes: 0f3a8c3f34f7 ("iio: Add support for creating IIO devices via configfs") Reported-by: Miguel Robles <miguel.robles@farole.net> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Daniel Baluta <daniel.baluta@gmail.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* Merge tag 'ib-mfd-iio-pwm-4.11' into testJonathan Cameron2017-01-281-0/+62
|\ | | | | | | | | | | | | Immutable branch between MFD, IIO and PWM due for the v4.11 merge window Pulled into IIO to allow follow up series of triggered capture for the STM32 ADCs.
| * iio: Add STM32 timer trigger driverBenjamin Gaignard2017-01-251-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Timers IPs can be used to generate triggers for other IPs like DAC or ADC. Each trigger may result of timer internals signals like counter enable, reset or edge, this configuration could be done through "master_mode" device attribute. Since triggers could be used by DAC or ADC their names are defined in include/ nux/iio/timer/stm32-timer-trigger.h and is_stm32_iio_timer_trigger function could be used to check if the trigger is valid or not. "trgo" trigger have a "sampling_frequency" attribute which allow to configure timer sampling frequency. version 8: - change kernel version from 4.10 to 4.11 in ABI documentation version 7: - remove all iio_device related code - move driver into trigger directory version 5: - simplify tables of triggers - only create an IIO device when needed version 4: - get triggers configuration from "reg" in DT - add tables of triggers - sampling frequency is enable/disable when writing in trigger sampling_frequency attribute - no more use of interruptions version 3: - change compatible to "st,stm32-timer-trigger" - fix attributes access right - use string instead of int for master_mode and slave_mode - document device attributes in sysfs-bus-iio-timer-stm32 version 2: - keep only one compatible - use st,input-triggers-names and st,output-triggers-names to know which triggers are accepted and/or create by the device Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
* | Merge tag 'iio-for-4.11a' of ↵Greg Kroah-Hartman2017-01-194-157/+179
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: First round of new device support, features and cleanups for IIO in the 4.11 cycle. It's shaping to be another fairly busy cycle. Lots more on the way! New device support * ads7950 - new driver supporting ads7950, ads7951, ads7952, ads7953, ads7954, ads7955, ads7956, ads7957, ads7958, ads7959, ads7960, and ads7961 ADCs. * cm3605 - New driver for this light sensor and proximity sensor which is an analog part with some additional digital controls. * hx711 - New driver. Core new stuff * Gravity sensor type. This is a processed datastream in which the device will try to work out which way is down. * Split the buffer.h file into two parts. One provides the interface to 'use' a buffer, the second provides the internals of the buffer functionality as needed by implementations of buffers. - Move documentation inline so as to allow use of private: tag when generating documentation. - Add some utility functions for the few things that are directly done with the buffers. - Stop exporting functions that no-one uses outside of the core code. - Push docs down by the code in the c file where they should have always been. - Fix typo in kernel-doc for buffer. - push down some includes that were previously happening implicitly. - stop enabling the timestamp of the dummy device. Features and cleanups * ad5592r - ACPI support * ad5593r -ACPI support. * ad5933 - Fix a false comment about size of a particular register. * ad7150 - replace S_IRUGO | S_IWUSR with 0644. I'm not that keen on these patches in general, but as it was nicely presented I took this one anyway. As a general rule will only take these as part of a larger driver cleanup. - don't eat an error but rather reutnr it in the write_event_config callback. * ad7606 - replace non standard range attibute with _scale * ade7753 - use usleep_range for short sleeps * ade7754 - use usleep_range for short sleeps * ade7758 - use usleep_range for short sleeps * ade7759 - use usleep_range for short sleeps * ade7854 - use usleep_range for short sleeps * adis16201 - fix description * adis16203 - fix description - fix copyright year * adis16209 - fix description * adt7316 - Add braces to arms of if else statement (for consistency) - Alignment fixes. * axp288 - Fix up an issue with accidental overwrites of data. * bmi160 - add deivce tables for i2c and spi to support correctly identifying the full dt name (including manufacturer). - device tree binding. * bmp280 - use usleep_range for short sleeps. * cm3232 - return error from cm3232_reg_init rather than eating it if the last write fails. * dummy driver - remove a semicolor found at end of a function defintition. * exynos-adc - use usleep_range for short sleeps. * hid-sensor (accel) - Add timestamp support. The hardware can provide timestamps so lets support them. If not fall back to timestamps estimated in kernel. * hid-sensor (light) - Add a duplicate ID for the light channels so as to keep existing interface whilst also using the more standard IIO interface. * hts221 - acpi probing * imx25-gcq - Add a macro call to allow this driver to be automatically loaded. * isl29028 - reorganise code to avoid deep nesting of if statements. - move chip test and default regs into a function suitable or sharing with power management code. - tidy up some code alignment. * lidar-lite-v3 - introduce compatible strings that make it clear Garmin have consideral friends. * mma8452 - avoid returning signed value when unsigned is appropriate * spmi-vadc - Update function for generic voltage conversion to take into account that different channels on this device should be handled differently. - Rework code to allow per channel voltage scaling and support the standard options for this hardware. - Fixup three minor issues with the above patches for this part. These all effect test builds rather than the native builds for the part, but good to clean them up anyway. * st_sensors - support device matching from the ACPI DST tables. - acpi based probing for accelerometers - acpi based probing for pressure sensors - Allow pressure sensors to read negative values. - Export sampling frequency for lps25h and lps331ap. - Add support for the old DT bindings from the period when these deivces were often supported through windows. Docs fixup: * typo in sysfs-bus-iio
| * | iio:buffer.h - split into buffer.h and buffer_impl.hJonathan Cameron2017-01-102-155/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | buffer.h supplies everything needed for devices using buffers. buffer_impl.h supplies access to the internals as needed to write a buffer implementation. This was really motivated by the mess that turned up in the kernel-doc documentation pulled in by the new sphinx docs. It made it clear that our logical separations in headers were generally terrible. The buffer case was easy to sort out without greatly effecting drivers so here it is. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffer: Push implementation of iio_device_attach_buffer into .c fileJonathan Cameron2017-01-101-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a precursor to the splitting of buffer.h into parts relevant to buffer implementation vs those for devices using buffers. struct buffer is about to become opaque as far as the header is concerned. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:kfifo_buf header include push down.Jonathan Cameron2017-01-101-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | As a precursor to splitting buffer.h, lets make sure all drivers include the relevant headers rather than relying on picking them up from kfifo_buf.h. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffer:iio_push_to_buffers_with_timestamp fix kernel-doc.Jonathan Cameron2017-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | Wrong start of kernel doc comment /* -> /** Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffers: Push some docs down into the .c file.Jonathan Cameron2017-01-101-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | Ancient legacy of me doing it wrong which it is nice to clear up whilst we are here. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffer: Stop exporting iio_scan_mask_queryJonathan Cameron2017-01-101-3/+0
| | | | | | | | | | | | | | | | | | | | | Nothing uses it outside of core code. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffer: Introduced a function to assign the buffer specific attrs.Jonathan Cameron2017-01-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is a necessary step in taking the buffer implementation opaque. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffer.h Reformat structure comments to be inline.Jonathan Cameron2017-01-101-37/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This should make it easier to see how the structure is split into public and private parts - reflected in the generated documentation. Deliberately use /* instead of /** for the private elements to avoid warnings when kernel-doc script runs. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio:buffer: Stop exporting iio_update_demuxJonathan Cameron2017-01-101-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Nothing outside of indiustrialio-buffer.c should be using this. Requires a large amount of juggling of functions to avoid a forward definition. Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
| * | iio: st_sensors: match sensors using ACPI handleShrirang Bagul2016-12-031-0/+9
| |/ | | | | | | | | | | | | | | Add support to match st sensors using information passed from ACPI DST tables. Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | iio: accel: st_accel: fix LIS3LV02 reading and scalingLinus Walleij2016-12-311-0/+12
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LIS3LV02 has a special bit that need to be set to get the read values left aligned. Before this patch we get gibberish like this: iio_generic_buffer -a -c10 -n lis3lv02dl_accel (...) 0.000000 -0.010042 -0.642688 19155832931907 0.000000 -0.010042 -0.642688 19155858751073 Which is because we read a raw value for 1g as 64 which is the nominal 1024 for 1g shifted 4 bits to the left by being right-aligned rather than left aligned. Since all other sensors are left aligned, add some code to set the special DAS (data alignment setting) bit to 1 so that the right value is now read like this: iio_generic_buffer -a -c10 -n lis3lv02dl_accel (...) 0.000000 -0.147095 -10.120135 24761614364956 -0.029419 -0.176514 -10.120135 24761631624540 The scaling was weird as well: we have a gain of 1000 for 1g and 3000 for 6g. I don't even remember how I came up with the old values but they are wrong. Fixes: 3acddf74f807 ("iio: st-sensors: add support for lis3lv02d accelerometer") Cc: Lorenzo Bianconi <lorenzo.bianconi@st.com> Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: inkern: add helpers to query available values from channelsPeter Rosin2016-11-132-0/+45
| | | | | | | | | | | | Specifically a helper for reading the available maximum raw value of a channel and a helper for forwarding read_avail requests for raw values from one iio driver to an iio channel that is consumed. These rather specific helpers are in turn built with generic helpers making it easy to build more helpers for available values as needed. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:core: add a callback to allow drivers to provide _available attributesJonathan Cameron2016-11-132-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A large number of attributes can only take a limited range of values. Currently in IIO this is handled by directly registering additional *_available attributes thus providing this information to userspace. It is desirable to provide this information via the core for much the same reason this was done for the actual channel information attributes in the first place. If it isn't there, then it can only really be accessed from userspace. Other in kernel IIO consumers have no access to what valid parameters are. Two forms are currently supported: * list of values in one particular IIO_VAL_* format. e.g. 1.300000 1.500000 1.730000 * range specification with a step size: e.g. [1.000000 0.500000 2.500000] equivalent to 1.000000 1.5000000 2.000000 2.500000 An addition set of masks are used to allow different sharing rules for the *_available attributes generated. This allows for example: in_accel_x_offset in_accel_y_offset in_accel_offset_available. We could have gone with having a specification for each and every info_mask element but that would have meant changing the existing userspace ABI. This approach does not. Signed-off-by: Jonathan Cameron <jic23@kernel.org> [forward ported, added some docs and fixed buffer overflows /peda] Acked-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: dac: mcp4725: support voltage reference selectionTomas Novotny2016-10-231-0/+11
| | | | | | | | | | | | MCP47x6 chip supports selection of a voltage reference (VDD, VREF buffered or unbuffered). MCP4725 doesn't have this feature thus the eventual setting is ignored and user is warned. The setting is stored only in the volatile memory of the chip. You need to manually store it to the EEPROM of the chip via 'store_eeprom' sysfs entry. Signed-off-by: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: dac: mcp4725: use regulator frameworkTomas Novotny2016-10-231-1/+0
| | | | | | | | | | | | | | Use a standard framework to get the reference voltage. It is done that way in the iio subsystem and it will simplify extending of the driver. Structure mcp4725_platform_data is left undeleted because it used in the next patch. This change breaks the current users of the driver, but there is no mainline user of struct mcp4725_platform_data. Signed-off-by: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* staging: iio: ad7192: implement IIO_CHAN_INFO_SAMP_FREQEva Rachel Retuya2016-10-111-0/+1
| | | | | | | | | | | | | | | | | This driver predates the availability of IIO_CHAN_INFO_SAMP_FREQ attribute wherein usage has some advantages like it can be accessed by in-kernel consumers as well as reduces the code size. Therefore, use IIO_CHAN_INFO_SAMP_FREQ to implement the sampling_frequency attribute instead of using IIO_DEV_ATTR_SAMP_FREQ() macro. Move code from the functions associated with IIO_DEV_ATTR_SAMP_FREQ() into respective read and write hooks with the mask set to IIO_CHAN_INFO_SAMP_FREQ. Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* include: linux: iio: add IIO_ATTR_{RO, WO, RW} and IIO_DEVICE_ATTR_{RO, WO, ↵Brian Masney2016-10-011-0/+24
| | | | | | | | | | | | | | RW} macros Add new macros: IIO_ATTR_RO, IIO_ATTR_WO, IIO_ATTR_RW, IIO_DEVICE_ATTR_RO, IIO_DEVICE_ATTR_WO and IIO_DEVICE_ATTR_RW to reduce the amount of boiler plate code that is needed for creating new attributes. This mimics the *_RO, *_WO, and *_RW macros that are found in include/linux/device.h and include/linux/sysfs.h. Signed-off-by: Brian Masney <masneyb@onstation.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Declare event_attrs field of iio_info structure as constBhumika Goyal2016-10-011-1/+1
| | | | | | | | | | | | The event_attrs field of iio_info structure is only initialized once whenever an object of iio_info is created. After that this field is never modified again anywhere in the kernel. So, declare event_attrs field of iio_info as a const struct attribute_group. Checked for occurences throughout the kernel using grep and coccinelle. Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: inkern: add iio_read_channel_offset helperMatt Ranostay2016-09-271-0/+13
| | | | | | | Allow access to underlying channel IIO_CHAN_INFO_OFFSET from a consumer. Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:trigger: Add helper function to verify that a trigger belongs to the ↵Lars-Peter Clausen2016-09-271-0/+2
| | | | | | | | | | | | | | | same device Some triggers can only be attached to the IIO device that corresponds to the same physical device. Currently each driver that requires this implements its own trigger validation function. Introduce a new helper function called iio_trigger_validate_own_device() that can be used to do this check. Having a common implementation avoids code duplication and unnecessary boiler-plate code. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* Merge tag 'iio-for-4.9b' of ↵Greg Kroah-Hartman2016-09-143-0/+37
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Second set of iio new device support, features and cleanups for the 4.9 cycle. New device support * ad8801 dac - new driver supporting ad8801 and ad8803 DACs. * adc12138 - new driver supporting TI adc12130/adc12132 and adc12138 ADCs. * ltc2485 adc - new driver * mxc6255 - add support for the mxc6225 part name and fixup the ID check so it works. * vz89x VOC sensor - add support for the vz89te part which drops the voc_short channel and adds CRCs compared to other supported parts. New features * core - immutable triggers. These effectively grant exclusive control over a trigger. The typical usecase is a device representing an analog part (perhaps a MUX) that needs to control the sampling of a downstream ADC. - resource managed trigger registration and triggered_buffer_init. - iio_push_event now protected against case of the event interface registration not having yet occured. Only matters if an interrupt can occur during this window - might happen on shared interrupt lines. - helper to let a driver query if the trigger it is using is provided by itself (using the convention of both device and trigger having the same parent). * tools - iio-utils. Used channel modifier scaling in preference to generic scaling when both exist. * at91-adc - Add support for touchscreen switches closure time needed by some newer parts. * stx104 - support the ADC channels on this ADC/DAC board. As these are the primary feature of the board also move the driver to the iio/adc directory. * sx9500 - device tree bindings. Cleanups / Fixes * ad5755 - fix an off-by-one on devnr limit check (introduced earlier this cycle) * ad7266 - drop NULL check on devm_regulator_get_optional as it can't return NULL. * ak8974 - avoid an unused functional warning due to rework in PM core code. - remove .owner field setting as done by i2c_core. * ina2xx - clear out a left over debug field from chip global data. * hid-sensors - avoid an unused functional warning due to rework in PM core code. * maxim-thermocouple - fix non static symbol warnings. * ms5611 - fetch and enable regulators unconditionally when they aren't optional. * sca3000 - whitespace cleanup. * st_sensors - fetch and enable regulators unconditionally rather than having them supported as optional regulators (missunderstanding on my part amongst others a while back) - followup to previous patch fixes error checking on the regulators. - mark symbols static where possible. - use the 'is it my trigger' help function. This prevents the odd case of another device triggering from the st-sensors trigger whilst the st-sensors trigger is itself not using it but rather using say an hrtimer. * ti-ads1015 - add missing of_node_put. * vz89x - rework to all support of new devices. - prevent reading of a corrupted buffer. - fixup a return value of 0/1 in a bool returning function. Address updates - Vlad Dogaru email address change.
| * iio: trigger: helpers to determine own triggerLinus Walleij2016-09-101-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a helper function to the IIO trigger framework: iio_trigger_using_own(): for an IIO device, this tells whether the device is using itself as a trigger. This is true if the indio device: (A) supplies a trigger and (B) has assigned its own buffer poll function to use this trigger. This helper function is good when constructing triggered, buffered drivers that can either use its own hardware *OR* an external trigger such as a HRTimer or even the trigger from a totally different sensor. Under such circumstances it is important to know for example if the timestamp from the same trigger hardware should be used when populating the buffer: if iio_trigger_using_own() is true, we can use this timestamp, else we need to pick a unique timestamp directly in the trigger handler. For this to work of course IIO devices registering hardware triggers must follow the convention to set the parent device properly, as as well as setting the parent of the IIO device itself. When a new poll function is attached, we check if the parent device of the IIO of the poll function is the same as the parent device of the trigger and in that case we conclude that the hardware is using itself as trigger. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Cc: Crestez Dan Leonard <leonard.crestez@intel.com> Cc: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| * iio: add resource managed triggered buffer init helpersGregor Boirie2016-09-042-0/+9
| | | | | | | | | | | | | | | | | | Add resource managed devm_iio_triggered_buffer_setup() and devm_iio_triggered_buffer_cleanup() to automatically clean up triggered buffers setup by IIO drivers, thus leading to simplified IIO drivers code. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| * iio:trigger: add resource managed (un)registerGregor Boirie2016-09-041-0/+6
| | | | | | | | | | | | | | | | | | Add resource managed devm_iio_trigger_register() and devm_iio_triger_unregister() to automatically clean up registered triggers allocated by IIO drivers, thus leading to simplified IIO drivers code. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
| * iio: trigger: allow immutable triggers to be assignedMatt Ranostay2016-09-032-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | There are times when an assigned trigger to a device shouldn't ever change after intialization. Examples of this being used is when an provider device has a trigger that is assigned to an ADC, which uses it populate data into a callback buffer. Signed-off-by: Matt Ranostay <matt@ranostay.consulting> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | Merge 4.8-rc5 into staging-nextGreg Kroah-Hartman2016-09-051-1/+1
|\ \ | |/ |/| | | | | | | We want the staging fixes in here as well to handle merge issues. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * iio: sw-trigger: Fix config group initializationLars-Peter Clausen2016-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the IS_ENABLED() helper macro to ensure that the configfs group is initialized either when configfs is built-in or when configfs is built as a module. Otherwise software trigger creation will result in undefined behaviour when configfs is built as a mdoule since the configfs group for the trigger is not properly initialized. Fixes: b662f809d410 ("iio: core: Introduce IIO software triggers") Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: Daniel Baluta <daniel.baluta@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | iio: buffer-callback: allow getting underlying iio_devMatt Ranostay2016-08-211-0/+12
|/ | | | | | | | | Add iio_channel_cb_get_iio_dev function to allow getting the underlying iio_dev. This is useful for setting the trigger of the consumer ADC device. Signed-off-by: Matt Ranostay <mranostay@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: st_sensors: harden interrupt handlingLinus Walleij2016-07-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leonard Crestez observed the following phenomenon: when using hard interrupt triggers (the DRDY line coming out of an ST sensor) sometimes a new value would arrive while reading the previous value, due to latencies in the system. We discovered that the ST hardware as far as can be observed is designed for level interrupts: the DRDY line will be held asserted as long as there are new values coming. The interrupt handler should be re-entered until we're out of values to handle from the sensor. If interrupts were handled as occurring on the edges (usually low-to-high) new values could appear and the line be held asserted after that, and these values would be missed, the interrupt handler would also lock up as new data was available, but as no new edges occurs on the DRDY signal, nothing happens: the edge detector only detects edges. To counter this, do the following: - Accept interrupt lines to be flagged as level interrupts using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line is marked like this (in the device tree node or ACPI table or similar) it will be utilized as a level IRQ. We mark the line with IRQF_ONESHOT and mask the IRQ while processing a sample, then the top half will be entered again if new values are available. - If we are flagged as using edge interrupts with IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove IRQF_ONESHOT so that the interrupt line is not masked while running the thread part of the interrupt. This way we will never miss an interrupt, then introduce a loop that polls the data ready registers repeatedly until no new samples are available, then exit the interrupt handler. This way we know no new values are available when the interrupt handler exits and new (edge) interrupts will be triggered when data arrives. Take some extra care to update the timestamp in the poll loop if this happens. The timestamp will not be 100% perfect, but it will at least be closer to the actual events. Usually the extra poll loop will handle the new samples, but once in a blue moon, we get a new IRQ while exiting the loop, before returning from the thread IRQ bottom half with IRQ_HANDLED. On these rare occasions, the removal of IRQF_ONESHOT means the interrupt will immediately fire again. - If no interrupt type is indicated from the DT/ACPI, choose IRQF_TRIGGER_RISING as default, as this is necessary for legacy boards. Tested successfully on the LIS331DL and L3G4200D by setting sampling frequency to 400Hz/800Hz and stressing the system: extra reads in the threaded interrupt handler occurs. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Tested-by: Crestez Dan Leonard <cdleonard@gmail.com> Reported-by: Crestez Dan Leonard <cdleonard@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:core: timestamping clock selection supportGregor Boirie2016-06-301-8/+14
| | | | | | | | | | | | | | | Adds a new per-device sysfs attribute "current_timestamp_clock" to allow userspace to select a particular POSIX clock for buffered samples and events timestamping. Following clocks, as listed in clock_gettime(2), are supported: CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME and CLOCK_TAI. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Acked-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* Merge 4.7-rc4 into staging-nextGreg Kroah-Hartman2016-06-201-1/+8
|\ | | | | | | | | | | | | We want the fixes in here, and we can resolve a merge issue in drivers/iio/industrialio-trigger.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * iio: st_sensors: switch to a threaded interruptLinus Walleij2016-05-291-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 98ad8b41f58dff6b30713d7f09ae3834b8df7ded ("iio: st_sensors: verify interrupt event to status") caused a regression when reading ST sensors from a HRTimer trigger rather than the intrinsic interrupts: the HRTimer may trigger faster than the sensor provides new values, and as the check against new values available as a cause of the interrupt trigger was done in the poll function, this would bail out of the HRTimer interrupt with IRQ_NONE. So clearly we need to only check the new values available from the proper interrupt handler and not from the poll function, which should rather just read the raw values from the registers, put them into the buffer and be happy. To achieve this: switch the ST Sensors over to using a true threaded interrupt handler. In the interrupt thread, check if new values are available, else yield to the (potential) next device on the same interrupt line to check the registers. If the interrupt was ours, proceed to poll the values. Instead of relying on iio_trigger_generic_data_rdy_poll() as a top half to wake up the thread that polls the sensor for new data, have the thread call iio_trigger_poll_chained() after determining that is is the proper source of the interrupt. This is modelled on drivers/iio/accel/mma8452.c which is already using a properly threaded interrupt handler. In order to get the same precision in timestamps as previously, where samples would be timestamped in the poll function pf->timestamp when calling iio_trigger_generic_data_rdy_poll() we introduce a local timestamp in the sensor data, set it in the top half (fastpath) of the interrupt handler and provide that to the core when calling iio_push_to_buffers_with_timestamp(). Additionally: if the active scanmask is not set for the sensor no IRQs should be enabled and we need to bail out with IRQ_NONE. This can happen if spurious IRQs fire when installing the threaded interrupt handler. Tested with hard interrupt triggers on LIS331DL, then also tested with hrtimers on the same sensor by creating a 75Hz HRTimer and using it to poll the sensor. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Reported-by: Crestez Dan Leonard <cdleonard@gmail.com> Tested-by: Crestez Dan Leonard <cdleonard@gmail.com> Tested-by: Jonathan Cameron <jic23@kernel.org> Fixes: 97865fe41322 ("iio: st_sensors: verify interrupt event to status") Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | iio:st_sensors: fix power regulator usageGregor Boirie2016-05-291-1/+1
| | | | | | | | | | | | | | Ensure failure to enable power regulators is properly handled. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | iio:st_sensors: unexport st_sensors_get_buffer_elementGregor Boirie2016-05-291-2/+0
| | | | | | | | | | | | | | | | Remove st_sensors_get_buffer_element symbol export since not explicitly used outside of st_sensors driver. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* | iio: Add support for creating IIO devices via configfsDaniel Baluta2016-05-041-0/+70
|/ | | | | | | | | | | | This is similar with support for creating triggers via configfs. Devices will be hosted under: * /config/iio/devices We allow users to register "device types" under: * /config/iio/devices/<device_types>/ Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:ak8975: add mounting matrix supportGregor Boirie2016-04-231-0/+16
| | | | | | | | | | | Expose a rotation matrix to indicate userspace the chip orientation with respect to the overall hardware system. Matrix is retrieved from "in_mount_matrix". It is declared into ak8975 DTS entry as a "mount-matrix" property. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:core: mounting matrix supportGregor Boirie2016-04-231-0/+31
| | | | | | | | | | | | | | | | | | | | Expose a rotation matrix to indicate userspace the chip placement with respect to the overall hardware system. This is needed to adjust coordinates sampled from a sensor chip when its position deviates from the main hardware system. Final coordinates computation is delegated to userspace since: * computation may involve floating point arithmetics ; * it allows an application to combine adjustments with arbitrary transformations. This 3 dimentional space rotation matrix is expressed as 3x3 array of strings to support floating point numbers. It may be retrieved from a "[<dir>_][<type>_]mount_matrix" sysfs attribute file. It is declared into a device / driver specific DTS property or platform data. Signed-off-by: Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: core: Add devm_ APIs for iio_channel_{get,release}_allLaxman Dewangan2016-04-191-0/+26
| | | | | | | | | | | | | | | | | | Some of kernel driver uses the IIO framework to get the sensor value via ADC or IIO HW driver. The client driver get iio channel by iio_channel_get_all() and release it by calling iio_channel_release_all(). Add resource managed version (devm_*) of these APIs so that if client calls the devm_iio_channel_get_all() then it need not to release it explicitly, it can be done by managed device framework when driver get un-binded. This reduces the code in error path and also need of .remove callback in some cases. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: core: Add devm_ APIs for iio_channel_{get,release}Laxman Dewangan2016-04-191-0/+27
| | | | | | | | | | | | | | | | Some of kernel driver uses the IIO framework to get the sensor value via ADC or IIO HW driver. The client driver get iio channel by iio_channel_get() and release it by calling iio_channel_release(). Add resource managed version (devm_*) of these APIs so that if client calls the devm_iio_channel_get() then it need not to release it explicitly, it can be done by managed device framework when driver get un-binded. This reduces the code in error path and also need of .remove callback in some cases. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: st_sensors: support open drain modeLinus Walleij2016-04-191-0/+6
| | | | | | | | | | | | | | | | | | | Some types of ST Sensors can be connected to the same IRQ line as other peripherals using open drain. Add a device tree binding and a sensor data property to flip the right bit in the interrupt control register to enable open drain mode on the INT line. If the line is set to be open drain, also tag on IRQF_SHARED to the IRQ flags when requesting the interrupt, as the whole point of using open drain interrupt lines is to share them with more than one peripheral (wire-or). Cc: devicetree@vger.kernel.org Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Acked-by: Rob Herring <rob@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: st_sensors: verify interrupt event to statusLinus Walleij2016-04-191-0/+3
| | | | | | | | | | | | | | | | | | This makes all ST sensor drivers check that they actually have new data available for the requested channel(s) before claiming an IRQ, by reading the status register (which is conveniently the same for all ST sensors) and check that the channel has new data before proceeding to read it and fill the buffer. This way sensors can share an interrupt line: it can be flaged as shared and then the sensor that did not fire will return NO_IRQ, and the sensor that fired will handle the IRQ and return IRQ_HANDLED. Cc: Giuseppe Barba <giuseppe.barba@st.com> Cc: Denis Ciocca <denis.ciocca@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio:adis: Add support for manual self-test flag clearLars-Peter Clausen2016-04-161-0/+1
| | | | | | | | | Some variants of the devices from the ADIS family don't auto-clear the self-test bit after the self-test has completed. Instead we have to manually clear. Add support for this to the ADIS library. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: buffer: add missing descriptions in iio_buffer_access_funcsLuis de Bethencourt2016-04-031-0/+2
| | | | | | | | | The members buffer_group and attrs of iio_buffer_access_funcs have no descriptions for the documentation. Adding them. Fixes: 08e7e0adaa17 ("iio: buffer: Allocate standard attributes in the core") Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: core: implement iio_device_{claim|release}_direct_mode()Alison Schofield2016-03-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | It is often the case that the driver wants to be sure a device stays in direct mode while it is executing a task or series of tasks. To accomplish this today, the driver performs this sequence: 1) take the device state lock, 2) verify it is not in a buffered mode, 3) execute some tasks, and 4) release that lock. This patch introduces a pair of helper functions that simplify these steps and make it more semantically expressive. iio_device_claim_direct_mode() If the device is not in any buffered mode it is guaranteed to stay that way until iio_release_direct_mode() is called. iio_device_release_direct_mode() Release the claim. Device is no longer guaranteed to stay in direct mode. Signed-off-by: Alison Schofield <amsfield22@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Fix typos in the struct iio_event_spec documentation commentsWilliam Breathitt Gray2016-02-171-3/+3
| | | | | | | | | | | | | This patch fixes a few minor typos in the documentation comments for the scan_type member of the iio_event_spec structure. The sign member name was improperly capitalized as "Sign" in the comments. The storagebits member name was improperly listed as "storage_bits" in the comments. The endianness member entry in the comments was moved after the repeat member entry in order to maintain consistency with the actual struct iio_event_spec layout. Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
* iio: Fix documentation for iio_dev mlockDaniel Baluta2016-02-081-1/+1
| | | | | | | | mlock *must* be used by core and drivers to protect access to devices state changes. Signed-off-by: Daniel Baluta <daniel.baluta@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
OpenPOWER on IntegriCloud