From 293487c8ecc1103f4625cea5e90e1ba0cc89660f Mon Sep 17 00:00:00 2001 From: Daniel Baluta Date: Tue, 10 Feb 2015 18:33:51 +0200 Subject: iio: Export userspace IIO headers 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 --- include/linux/iio/events.h | 30 +----------------- include/linux/iio/types.h | 78 +--------------------------------------------- 2 files changed, 2 insertions(+), 106 deletions(-) (limited to 'include/linux') diff --git a/include/linux/iio/events.h b/include/linux/iio/events.h index 03fa332ad2a8..8ad87d1c5340 100644 --- a/include/linux/iio/events.h +++ b/include/linux/iio/events.h @@ -9,22 +9,8 @@ #ifndef _IIO_EVENTS_H_ #define _IIO_EVENTS_H_ -#include -#include #include - -/** - * struct iio_event_data - The actual event being pushed to userspace - * @id: event identifier - * @timestamp: best estimate of time of event occurrence (often from - * the interrupt handler) - */ -struct iio_event_data { - __u64 id; - __s64 timestamp; -}; - -#define IIO_GET_EVENT_FD_IOCTL _IOR('i', 0x90, int) +#include /** * IIO_EVENT_CODE() - create event identifier @@ -70,18 +56,4 @@ struct iio_event_data { #define IIO_UNMOD_EVENT_CODE(chan_type, number, type, direction) \ IIO_EVENT_CODE(chan_type, 0, 0, direction, type, number, 0, 0) -#define IIO_EVENT_CODE_EXTRACT_TYPE(mask) ((mask >> 56) & 0xFF) - -#define IIO_EVENT_CODE_EXTRACT_DIR(mask) ((mask >> 48) & 0x7F) - -#define IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(mask) ((mask >> 32) & 0xFF) - -/* Event code number extraction depends on which type of event we have. - * Perhaps review this function in the future*/ -#define IIO_EVENT_CODE_EXTRACT_CHAN(mask) ((__s16)(mask & 0xFFFF)) -#define IIO_EVENT_CODE_EXTRACT_CHAN2(mask) ((__s16)(((mask) >> 16) & 0xFFFF)) - -#define IIO_EVENT_CODE_EXTRACT_MODIFIER(mask) ((mask >> 40) & 0xFF) -#define IIO_EVENT_CODE_EXTRACT_DIFF(mask) (((mask) >> 55) & 0x1) - #endif diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h index 580ed5bdb3fa..942b6de68e2f 100644 --- a/include/linux/iio/types.h +++ b/include/linux/iio/types.h @@ -10,76 +10,7 @@ #ifndef _IIO_TYPES_H_ #define _IIO_TYPES_H_ -enum iio_chan_type { - IIO_VOLTAGE, - IIO_CURRENT, - IIO_POWER, - IIO_ACCEL, - IIO_ANGL_VEL, - IIO_MAGN, - IIO_LIGHT, - IIO_INTENSITY, - IIO_PROXIMITY, - IIO_TEMP, - IIO_INCLI, - IIO_ROT, - IIO_ANGL, - IIO_TIMESTAMP, - IIO_CAPACITANCE, - IIO_ALTVOLTAGE, - IIO_CCT, - IIO_PRESSURE, - IIO_HUMIDITYRELATIVE, - IIO_ACTIVITY, - IIO_STEPS, - IIO_ENERGY, - IIO_DISTANCE, - IIO_VELOCITY, -}; - -enum iio_modifier { - IIO_NO_MOD, - IIO_MOD_X, - IIO_MOD_Y, - IIO_MOD_Z, - IIO_MOD_X_AND_Y, - IIO_MOD_X_AND_Z, - IIO_MOD_Y_AND_Z, - IIO_MOD_X_AND_Y_AND_Z, - IIO_MOD_X_OR_Y, - IIO_MOD_X_OR_Z, - IIO_MOD_Y_OR_Z, - IIO_MOD_X_OR_Y_OR_Z, - IIO_MOD_LIGHT_BOTH, - IIO_MOD_LIGHT_IR, - IIO_MOD_ROOT_SUM_SQUARED_X_Y, - IIO_MOD_SUM_SQUARED_X_Y_Z, - IIO_MOD_LIGHT_CLEAR, - IIO_MOD_LIGHT_RED, - IIO_MOD_LIGHT_GREEN, - IIO_MOD_LIGHT_BLUE, - IIO_MOD_QUATERNION, - IIO_MOD_TEMP_AMBIENT, - IIO_MOD_TEMP_OBJECT, - IIO_MOD_NORTH_MAGN, - IIO_MOD_NORTH_TRUE, - IIO_MOD_NORTH_MAGN_TILT_COMP, - IIO_MOD_NORTH_TRUE_TILT_COMP, - IIO_MOD_RUNNING, - IIO_MOD_JOGGING, - IIO_MOD_WALKING, - IIO_MOD_STILL, - IIO_MOD_ROOT_SUM_SQUARED_X_Y_Z, -}; - -enum iio_event_type { - IIO_EV_TYPE_THRESH, - IIO_EV_TYPE_MAG, - IIO_EV_TYPE_ROC, - IIO_EV_TYPE_THRESH_ADAPTIVE, - IIO_EV_TYPE_MAG_ADAPTIVE, - IIO_EV_TYPE_CHANGE, -}; +#include enum iio_event_info { IIO_EV_INFO_ENABLE, @@ -88,13 +19,6 @@ enum iio_event_info { IIO_EV_INFO_PERIOD, }; -enum iio_event_direction { - IIO_EV_DIR_EITHER, - IIO_EV_DIR_RISING, - IIO_EV_DIR_FALLING, - IIO_EV_DIR_NONE, -}; - #define IIO_VAL_INT 1 #define IIO_VAL_INT_PLUS_MICRO 2 #define IIO_VAL_INT_PLUS_NANO 3 -- cgit v1.2.3 From c74a804f115bdedcac72ea52ca33f46cfae3b74f Mon Sep 17 00:00:00 2001 From: Dmitry Kalinkin Date: Thu, 26 Feb 2015 18:53:10 +0300 Subject: staging: vme: mmap() support for vme_user We also make sure that user won't be able to reconfigure the window while it is mmap'ed. Signed-off-by: Dmitry Kalinkin Cc: Martyn Welch Cc: Igor Alekseev Signed-off-by: Greg Kroah-Hartman --- include/linux/vme.h | 1 + 1 file changed, 1 insertion(+) (limited to 'include/linux') diff --git a/include/linux/vme.h b/include/linux/vme.h index 8cd6f19ca518..79242e9c06b8 100644 --- a/include/linux/vme.h +++ b/include/linux/vme.h @@ -137,6 +137,7 @@ ssize_t vme_master_read(struct vme_resource *, void *, size_t, loff_t); ssize_t vme_master_write(struct vme_resource *, void *, size_t, loff_t); unsigned int vme_master_rmw(struct vme_resource *, unsigned int, unsigned int, unsigned int, loff_t); +int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct *vma); void vme_master_free(struct vme_resource *); struct vme_resource *vme_dma_request(struct vme_dev *, u32); -- cgit v1.2.3 From a878a1a61a1f0e4b23602ddd87b1408a7a748d0e Mon Sep 17 00:00:00 2001 From: Antonio Fiol Date: Sat, 28 Mar 2015 09:07:14 +0100 Subject: iio: max517: Add support for MAX520 and MAX521 chips. 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 --- include/linux/iio/dac/max517.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'include/linux') diff --git a/include/linux/iio/dac/max517.h b/include/linux/iio/dac/max517.h index f6d1d252f08d..7668716cd73c 100644 --- a/include/linux/iio/dac/max517.h +++ b/include/linux/iio/dac/max517.h @@ -9,7 +9,7 @@ #define IIO_DAC_MAX517_H_ struct max517_platform_data { - u16 vref_mv[2]; + u16 vref_mv[8]; }; #endif /* IIO_DAC_MAX517_H_ */ -- cgit v1.2.3 From 37d3455672732b29a477732a94abfe95e199f0ce Mon Sep 17 00:00:00 2001 From: Josselin Costanzi Date: Sun, 22 Mar 2015 20:33:38 +0200 Subject: iio: add watermark logic to iio read and poll 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 --- include/linux/iio/buffer.h | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'include/linux') diff --git a/include/linux/iio/buffer.h b/include/linux/iio/buffer.h index b65850a41127..eb8622b78ec9 100644 --- a/include/linux/iio/buffer.h +++ b/include/linux/iio/buffer.h @@ -21,8 +21,8 @@ struct iio_buffer; * struct iio_buffer_access_funcs - access functions for buffers. * @store_to: actually store stuff to the buffer * @read_first_n: try to get a specified number of bytes (must exist) - * @data_available: indicates whether data for reading from the buffer is - * available. + * @data_available: indicates how much data is available for reading from + * the buffer. * @request_update: if a parameter change has been marked, update underlying * storage. * @set_bytes_per_datum:set number of bytes per datum @@ -43,7 +43,7 @@ struct iio_buffer_access_funcs { int (*read_first_n)(struct iio_buffer *buffer, size_t n, char __user *buf); - bool (*data_available)(struct iio_buffer *buffer); + size_t (*data_available)(struct iio_buffer *buffer); int (*request_update)(struct iio_buffer *buffer); @@ -72,6 +72,7 @@ struct iio_buffer_access_funcs { * @demux_bounce: [INTERN] buffer for doing gather from incoming scan. * @buffer_list: [INTERN] entry in the devices list of current buffers. * @ref: [INTERN] reference count of the buffer. + * @watermark: [INTERN] number of datums to wait for poll/read. */ struct iio_buffer { int length; @@ -90,6 +91,7 @@ struct iio_buffer { void *demux_bounce; struct list_head buffer_list; struct kref ref; + unsigned int watermark; }; /** -- cgit v1.2.3 From f4f4673b7535eff4ee1a8cfb1685fa1e1a0cb79d Mon Sep 17 00:00:00 2001 From: Octavian Purdila Date: Sun, 22 Mar 2015 20:33:39 +0200 Subject: iio: add support for hardware fifo 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 --- include/linux/iio/iio.h | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'include/linux') diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h index 80d855061064..d86b753e9b30 100644 --- a/include/linux/iio/iio.h +++ b/include/linux/iio/iio.h @@ -338,6 +338,16 @@ struct iio_dev; * provide a custom of_xlate function that reads the * *args* and returns the appropriate index in registered * IIO channels array. + * @hwfifo_set_watermark: function pointer to set the current hardware + * fifo watermark level; see hwfifo_* entries in + * Documentation/ABI/testing/sysfs-bus-iio for details on + * how the hardware fifo operates + * @hwfifo_flush_to_buffer: function pointer to flush the samples stored + * in the hardware fifo to the device buffer. The driver + * should not flush more than count samples. The function + * must return the number of samples flushed, 0 if no + * samples were flushed or a negative integer if no samples + * were flushed and there was an error. **/ struct iio_info { struct module *driver_module; @@ -399,6 +409,9 @@ struct iio_info { unsigned *readval); int (*of_xlate)(struct iio_dev *indio_dev, const struct of_phandle_args *iiospec); + int (*hwfifo_set_watermark)(struct iio_dev *indio_dev, unsigned val); + int (*hwfifo_flush_to_buffer)(struct iio_dev *indio_dev, + unsigned count); }; /** -- cgit v1.2.3