user/sven/linux.git/include/linux/iio, branch v4.2.5

iio: Add inverse unit conversion macros

2015-09-21T17:10:44Z

commit c689a923c867eac40ed3826c1d9328edea8b6bc7 upstream. Add inverse unit conversion macro to convert from standard IIO units to units that might be used by some devices. Those are useful in combination with scale factors that are specified as IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will contain the maximum raw value the sensor will generate and the numerator the value it maps to in a specific unit. Sometimes datasheets specify those in different units than the standard IIO units (e.g. degree/s instead of rad/s) and so we need to do a unit conversion. From a mathematical point of view it does not make a difference whether we apply the unit conversion to the numerator or the inverse unit conversion to the denominator since (x / y) / z = x / (y * z). But as the denominator is typically a larger value and we are rounding both the numerator and denominator to integer values using the later method gives us a better precision (E.g. the relative error is smaller if we round 8000.3 to 8000 rather than rounding 8.3 to 8). This is where in inverse unit conversion macros will be used. Marked for stable as used by some upcoming fixes. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: Specify supported modes for buffers

2015-06-01T10:31:12Z

For each buffer type specify the supported device modes for this buffer. This allows us for devices which support multiple different operating modes to pick the correct operating mode based on the modes supported by the attached buffers. It also prevents that buffers with conflicting modes are attached to a device at the same time or that a buffer with a non-supported mode is attached to a device (e.g. in-kernel callback buffer to a device only supporting hardware mode). Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron

iio: core: add high pass filter attributes

2015-05-17T09:32:35Z

Add a high pass filter attribute for measurements (like the existing low pass) Also add both high and low pass attributes for events. Signed-off-by: Martin Fuzzey Signed-off-by: Jonathan Cameron

iio: core: Introduce IIO_CHAN_INFO_OVERSAMPLING_RATIO

2015-05-10T19:31:44Z

Some magnetometers can perform a number of repetitions in HW for each measurement to increase accuracy. One example is Bosch BMC150: http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf. Introduce an interface to set the oversampling ratio for these devices. Signed-off-by: Irina Tirdea Signed-off-by: Jonathan Cameron

iio: core: Introduce IIO_CHAN_INFO_CALIBEMISSIVITY

2015-04-09T14:03:05Z

Contact-less IR temperature sensors measure the temperature of an object by using its thermal radiation. Surfaces with different emissivity ratios emit different amounts of energy at the same temperature. IIO_CHAN_INFO_CALIBEMISSIVITY allows the user to inform the sensor of the emissivity of the object in front of it, in order to effectively measure its temperature. A device providing such setting is Melexis's MLX90614: http://melexis.com/Assets/IR-sensor-thermometer-MLX90614-Datasheet-5152.aspx. Signed-off-by: Vianney le Clément de Saint-Marcq Cc: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Jonathan Cameron

iio: add support for hardware fifo

2015-03-29T15:17:10Z

Some devices have hardware buffers that can store a number of samples for later consumption. Hardware usually provides interrupts to notify the processor when the FIFO is full or when it has reached a certain watermark level. This helps with reducing the number of interrupts to the host processor and thus it helps decreasing the power consumption. This patch enables usage of hardware FIFOs for IIO devices in conjunction with software device buffers. When the hardware FIFO is enabled the samples are stored in the hardware FIFO. The samples are later flushed to the device software buffer when the number of entries in the hardware FIFO reaches the hardware watermark or when a flush operation is triggered by the user when doing a non-blocking read on an empty software device buffer. In order to implement hardware FIFO support the device drivers must implement the following new operations: setting and getting the hardware FIFO watermark level, flushing the hardware FIFO to the software device buffer. The device must also expose information about the hardware FIFO such it's minimum and maximum watermark and if necessary a list of supported watermark values. Finally, the device driver must activate the hardware FIFO when the device buffer is enabled, if the current device settings allows it. The software device buffer watermark is passed by the IIO core to the device driver as a hint for the hardware FIFO watermark. The device driver can adjust this value to allow for hardware limitations (such as capping it to the maximum hardware watermark or adjust it to a value that is supported by the hardware). It can also disable the hardware watermark (and implicitly the hardware FIFO) it this value is below the minimum hardware watermark. Since a driver may support hardware FIFO only when not in triggered buffer mode (due to different semantics of hardware FIFO sampling and triggered sampling) this patch changes the IIO core code to allow falling back to non-triggered buffered mode if no trigger is enabled. Signed-off-by: Octavian Purdila Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron

iio: add watermark logic to iio read and poll

2015-03-29T15:17:09Z

Currently the IIO buffer blocking read only wait until at least one data element is available. This patch makes the reader sleep until enough data is collected before returning to userspace. This should limit the read() calls count when trying to get data in batches. Co-author: Yannick Bedhomme Signed-off-by: Josselin Costanzi [rebased and remove buffer timeout] Signed-off-by: Octavian Purdila Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron

iio: max517: Add support for MAX520 and MAX521 chips.

2015-03-28T10:57:34Z

MAX520 and MAX521 are protocol-compatible with the already supported chips, just have more channels. Signed-off-by: Antonio Fiol Signed-off-by: Jonathan Cameron

iio: Export userspace IIO headers

2015-02-14T17:05:03Z

After UAPI header file split [1] all user-kernel interfaces were placed under include/uapi/. This patch moves IIO user specific API from: * include/linux/iio/events.h => include/uapi/linux/iio/events.h * include/linux/types.h => include/uapi/linux/types.h Now there is no need for nasty tricks to compile userspace programs (e.g iio_event_monitor). Just installing the kernel headers with make headers_install command does the job. [1] http://lwn.net/Articles/507794/ Signed-off-by: Daniel Baluta Signed-off-by: Jonathan Cameron

iio: core: Introduce IIO_CHAN_INFO_DEBOUNCE_COUNT and _TIME

2015-01-29T18:49:57Z

The pedometer needs to filter out false steps that might be generated by tapping the foot, sitting, etc. To do that it computes the number of steps that occur in a given time and decides the user is moving only if this value is over a threshold. E.g.: the user starts moving only if he takes 4 steps in 3 seconds. This filter is applied only when the user starts moving. A device that has such pedometer functionality is Freescale's MMA9553L: http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf. To export this feature, this patch introduces IIO_CHAN_INFO_DEBOUNCE_COUNT and IIO_CHAN_INFO_DEBOUNCE_TIME. For the pedometer, in_steps_debounce_count will specify the number of steps that need to occur in in_steps_debounce_time seconds so that the pedometer decides the user is moving. Signed-off-by: Irina Tirdea Signed-off-by: Jonathan Cameron