Skip to content

L
linux
Switch branch/tag
  1. 22 Nov, 2015 1 commit
  3. 21 Nov, 2015 2 commits
  5. 18 Nov, 2015 2 commits
  7. 15 Nov, 2015 5 commits
  9. 14 Nov, 2015 1 commit
  11. 08 Nov, 2015 4 commits
  13. 01 Nov, 2015 1 commit
  15. 31 Oct, 2015 1 commit
  17. 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
      iio:adc: add iio driver for Palmas (twl6035/7) gpadc · e08e19c3
      H. Nikolaus Schaller authored 
      This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.
Signed-off-by: default avatarPradeep Goudagunta <pgoudagunta@nvidia.com>
Signed-off-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: default avatarMarek Belisko <marek@goldelico.com>
Acked-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: default avatarJonathan Cameron <jic23@kernel.org>
Acked-by: default avatarLee Jones <lee.jones@linaro.org>
Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      e08e19c3
    • 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
  19. 18 Oct, 2015 10 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7