pm24.git/include/linux/iio, branch v4.6-rc7

iio: Fix typos in the struct iio_event_spec documentation comments

2016-02-17T21:11:08Z

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 Signed-off-by: Jonathan Cameron

iio: Fix documentation for iio_dev mlock

2016-02-08T18:34:32Z

mlock *must* be used by core and drivers to protect access to devices state changes. Signed-off-by: Daniel Baluta Signed-off-by: Jonathan Cameron

iio: st_sensors: support active-low interrupts

2016-01-10T12:35:32Z

Most ST MEMS Sensors that support interrupts can also handle sending an active low interrupt, i.e. going from high to low on data ready (or other interrupt) and thus triggering on a falling edge to the interrupt controller. Set up logic to inspect the interrupt line we get for a sensor: if it is triggering on rising edge, leave everything alone, but if it triggers on falling edges, set up active low, and if unsupported configurations appear: warn with errors and reconfigure the interrupt to a rising edge, which all interrupt generating sensors support. Create a local header for st_sensors_core.h to share functions between the sensor core and the trigger setup code. Cc: Giuseppe Barba Cc: Denis Ciocca Signed-off-by: Linus Walleij Signed-off-by: Jonathan Cameron

iio: Make IIO value formating function globally available.

2015-12-22T17:04:56Z

Make IIO value formating function globally available to allow IIO drivers to output values as the core does. Signed-off-by: Andrew F. Davis Signed-off-by: Jonathan Cameron

iio:configfs: Introduce iio/configfs.h to provide a location for the configfs_subsystem

2015-12-05T16:25:30Z

This exported element needs to be accesible to all drivers using configfs within IIO. Previously it was in the sw_trig.h file which only convered one such usecase. This also fixes a sparse warning as it is now in a header that makes sense to include from industrialio-configfs.c Signed-off-by: Jonathan Cameron < jic23@kernel.org>

iio: core: Introduce IIO software triggers

2015-12-03T18:19:27Z

A software trigger associates an IIO device trigger with a software interrupt source (e.g: timer, sysfs). This patch adds the generic infrastructure for handling software triggers. Software interrupts sources are kept in a iio_trigger_types_list and registered separately when the associated kernel module is loaded. Software triggers can be created directly from drivers or from user space via configfs interface. To sum up, this dynamically creates "triggers" group to be found under /config/iio/triggers and offers the possibility of dynamically creating trigger types groups. The first supported trigger type is "hrtimer" found under /config/iio/triggers/hrtimer. Signed-off-by: Daniel Baluta Signed-off-by: Jonathan Cameron

iio: Add a DMAengine framework based buffer

2015-10-25T13:55:32Z

Add a generic fully device independent DMA buffer implementation that uses the DMAegnine framework to perform the DMA transfers. This can be used by converter drivers that whish to provide a DMA buffer for converters that are connected to a DMA core that implements the DMAengine API. Apart from allocating the buffer using iio_dmaengine_buffer_alloc() and freeing it using iio_dmaengine_buffer_free() no additional converter driver specific code is required when using this DMA buffer implementation. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron

iio: Add generic DMA buffer infrastructure

2015-10-25T13:54:34Z

The traditional approach used in IIO to implement buffered capture requires the generation of at least one interrupt per sample. In the interrupt handler the driver reads the sample from the device and copies it to a software buffer. This approach has a rather large per sample overhead associated with it. And while it works fine for samplerates in the range of up to 1000 samples per second it starts to consume a rather large share of the available CPU processing time once we go beyond that, this is especially true on an embedded system with limited processing power. The regular interrupt also causes increased power consumption by not allowing the hardware into deeper sleep states, which is something that becomes more and more important on mobile battery powered devices. And while the recently added watermark support mitigates some of the issues by allowing the device to generate interrupts at a rate lower than the data output rate, this still requires a storage buffer inside the device and even if it exists it is only a few 100 samples deep at most. DMA support on the other hand allows to capture multiple millions or even more samples without any CPU interaction. This allows the CPU to either go to sleep for longer periods or focus on other tasks which increases overall system performance and power consumption. In addition to that some devices might not even offer a way to read the data other than using DMA, which makes DMA mandatory to use for them. The tasks involved in implementing a DMA buffer can be divided into two categories. The first category is memory buffer management (allocation, mapping, etc.) and hooking this up the IIO buffer callbacks like read(), enable(), disable(), etc. The second category of tasks is to setup the DMA hardware and manage the DMA transfers. Tasks from the first category will be very similar for all IIO drivers supporting DMA buffers, while the tasks from the second category will be hardware specific. This patch implements a generic infrastructure that take care of the former tasks. It provides a set of functions that implement the standard IIO buffer iio_buffer_access_funcs callbacks. These can either be used as is or be overloaded and augmented with driver specific code where necessary. For the DMA buffer support infrastructure that is introduced in this series sample data is grouped by so called blocks. A block is the basic unit at which data is exchanged between the application and the hardware. The application is responsible for allocating the memory associated with the block and then passes the block to the hardware. When the hardware has captured the amount of samples equal to size of a block it will notify the application, which can then read the data from the block and process it. The block size can freely chosen (within the constraints of the hardware). This allows to make a trade-off between latency and management overhead. The larger the block size the lower the per sample overhead but the latency between when the data was captured and when the application will be able to access it increases, in a similar way smaller block sizes have a larger per sample management overhead but a lower latency. The ideal block size thus depends on system and application requirements. For the time being the infrastructure only implements a simple double buffered scheme which allocates two blocks each with half the size of the configured buffer size. This provides basic support for capturing continuous uninterrupted data over the existing file-IO ABI. Future extensions to the DMA buffer infrastructure will give applications a more fine grained control over how many blocks are allocated and the size of each block. But this requires userspace ABI additions which are intentionally not part of this patch and will be added separately. Tasks of the second category need to be implemented by a device specific driver. They can be hooked up into the generic infrastructure using two simple callbacks, submit() and abort(). The submit() callback is used to schedule DMA transfers for blocks. Once a DMA transfer has been completed it is expected that the buffer driver calls iio_dma_buffer_block_done() to notify. The abort() callback is used for stopping all pending and active DMA transfers when the buffer is disabled. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron

iio: Add buffer enable/disable callbacks

2015-10-25T13:52:31Z

This patch adds a enable and disable callback that is called when the buffer is enabled/disabled. This can be used by buffer implementations that need to do some setup or teardown work. E.g. a DMA based buffer can use this to start/stop the DMA transfer. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron

iio: Add support for indicating fixed watermarks

2015-10-25T13:51:11Z

For buffers which have a fixed wake-up watermark the watermark attribute should be read-only. Add a new FIXED_WATERMARK flag to the struct iio_buffer_access_funcs, which can be set by a buffer implementation. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron