1. 21 Nov, 2015 1 commit
  2. 18 Nov, 2015 2 commits
  3. 15 Nov, 2015 5 commits
  4. 14 Nov, 2015 1 commit
  5. 08 Nov, 2015 4 commits
  6. 01 Nov, 2015 1 commit
  7. 31 Oct, 2015 1 commit
  8. 25 Oct, 2015 13 commits
    • Lars-Peter Clausen's avatar
      iio: Add a DMAengine framework based buffer · 2d6ca60f
      Lars-Peter Clausen authored
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      2d6ca60f
    • Lars-Peter Clausen's avatar
      iio: Add generic DMA buffer infrastructure · 670b19ae
      Lars-Peter Clausen authored
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      670b19ae
    • Lars-Peter Clausen's avatar
      iio: Add buffer enable/disable callbacks · e18a2ad4
      Lars-Peter Clausen authored
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      e18a2ad4
    • Lars-Peter Clausen's avatar
      iio: Add support for indicating fixed watermarks · b440655b
      Lars-Peter Clausen authored
      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: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      b440655b
    • Lars-Peter Clausen's avatar
      iio:iio_buffer_init(): Only set watermark if not already set · 4a605357
      Lars-Peter Clausen authored
      Only initialize the watermark field if it is still 0. This allows drivers
      to provide a custom default watermark value. E.g. some driver might have a
      fixed watermark or can only support watermarks within a certain range and
      the initial value for the watermark should be within this range.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      4a605357
    • Lars-Peter Clausen's avatar
      iio: Set device watermark based on watermark of all attached buffers · f0566c0c
      Lars-Peter Clausen authored
      Currently the watermark of the device is only set based on the watermark
      that is set for the user space buffer. This doesn't consider the watermarks
      set on any attached in-kernel buffers.
      
      Change this so that the watermark of the device should be the minimum of
      the watermarks over all attached buffers.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      f0566c0c
    • Javier Martinez Canillas's avatar
      iio: adc: mcp320x: Add compatible with vendor prefix to OF table · 0d0e5384
      Javier Martinez Canillas authored
      The driver Device Tree binding now documents compatible strings that have
      a vendor prefix, so add these to the OF device ID table to match and mark
      the old ones as deprecated explaining that should not be used anymore.
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Acked-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      0d0e5384
    • Javier Martinez Canillas's avatar
      iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix · 3a872138
      Javier Martinez Canillas authored
      The Microchip Analog to Digital Converter (ADC) Device Tree binding
      documents compatible strings with no vendor prefix. Since it should
      compatible strings with also a vendor, add these to the binding doc
      and mark the old ones as deprecated.
      
      The driver says that the device is from Microchip Technology which
      is listed in Documentation/devicetree/bindings/vendor-prefixes.txt
      so use the documented prefix.
      Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
      Acked-by: default avatarMichael Welling <mwelling@ieee.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      3a872138
    • Cristina Opriceana's avatar
      iio: Move IIO Dummy Driver out of staging · 415f7924
      Cristina Opriceana authored
      This patch moves the reference IIO dummy driver from drivers/staging/iio
      into a separate folder, drivers/iio/dummy and adds the proper Kconfig
      and Makefile for it.
      
      A new config menu entry called IIO dummy driver has also been added
      in the Industrial I/O support menu, corresponding to this driver.
      Signed-off-by: default avatarCristina Opriceana <cristina.opriceana@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      415f7924
    • Marek Belisko's avatar
      iio:adc:palmas: add DT support · f0b16435
      Marek Belisko authored
      Code was found at:
      https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: Marek Belisko <marek@goldelico.com> [Fixed minor typos + add channels list to documentation]
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      f0b16435
    • H. Nikolaus Schaller's avatar
    • Teodora Baluta's avatar
      iio: accel: add support for Memsic MXC6255XC sensor · 75b6548f
      Teodora Baluta authored
      This patch adds a minimal implementation for the Memsic MXC6255XC
      orientation sensing accelerometer. The supported operations are reading
      raw acceleration values for X/Y axis that can be scaled using the
      exposed scale.
      Signed-off-by: default avatarTeodora Baluta <teodora.baluta@intel.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      75b6548f
    • Martin Kepplinger's avatar
      iio: mma8452: support either of the available interrupt pins · d2a3e093
      Martin Kepplinger authored
      This change is important in order for everyone to be easily able to use the
      driver for one of the supported accelerometer chips!
      
      Until now, the driver blindly assumed that the INT1 interrupt line is wired
      on a user's board. But these devices have 2 interrupt lines and can route
      their interrupt sources to one of them. Now, if "INT2" is found and matches
      i2c_client->irq, INT2 will be used.
      
      The chip's default actually is INT2, which is why probably many boards will
      have it wired and can make use of this.
      
      Of course, this also falls back to assuming INT1, so for existing users
      nothing will break. The new functionality is described in the bindings doc.
      Signed-off-by: default avatarMartin Kepplinger <martin.kepplinger@theobroma-systems.com>
      For the binding: Acked-by: Rob Herring <robh@kernel.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      d2a3e093
  9. 18 Oct, 2015 12 commits