Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 03 4月, 2016 1 次提交
  3. 12 3月, 2016 1 次提交
    • A
      iio: core: implement iio_device_{claim|release}_direct_mode() · 08a33805
      由 Alison Schofield 提交于 
      It is often the case that the driver wants to be sure a device stays
in direct mode while it is executing a task or series of tasks.  To
accomplish this today, the driver performs this sequence: 1) take the
device state lock, 2) verify it is not in a buffered mode, 3) execute
some tasks, and 4) release that lock.

This patch introduces a pair of helper functions that simplify these
steps and make it more semantically expressive.

iio_device_claim_direct_mode()
        If the device is not in any buffered mode it is guaranteed
        to stay that way until iio_release_direct_mode() is called.

iio_device_release_direct_mode()
        Release the claim. Device is no longer guaranteed to stay
        in direct mode.
Signed-off-by: NAlison Schofield <amsfield22@gmail.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      08a33805
  5. 18 2月, 2016 1 次提交
  7. 09 2月, 2016 1 次提交
  9. 10 1月, 2016 1 次提交
    • L
      iio: st_sensors: support active-low interrupts · a9fd053b
      由 Linus Walleij 提交于 
      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 <giuseppe.barba@st.com>
Cc: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      a9fd053b
  11. 23 12月, 2015 1 次提交
  13. 06 12月, 2015 1 次提交
  15. 04 12月, 2015 1 次提交
    • D
      iio: core: Introduce IIO software triggers · b662f809
      由 Daniel Baluta 提交于 
      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: NDaniel Baluta <daniel.baluta@intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      b662f809
  17. 25 10月, 2015 4 次提交
    • L
      iio: Add a DMAengine framework based buffer · 2d6ca60f
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      2d6ca60f
    • L
      iio: Add generic DMA buffer infrastructure · 670b19ae
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      670b19ae
    • L
      iio: Add buffer enable/disable callbacks · e18a2ad4
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      e18a2ad4
    • L
      iio: Add support for indicating fixed watermarks · b440655b
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      b440655b
  19. 28 8月, 2015 1 次提交
  21. 16 8月, 2015 1 次提交
  23. 08 8月, 2015 2 次提交
    • L
      iio: Add inverse unit conversion macros · c689a923
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      c689a923
    • P
      iio: declare struct to fix warning · ad30bad3
      由 Pengyu Ma 提交于 
      When compile iio related driver the following warning shown:

include/linux/iio/trigger.h:35:34: warning: 'struct iio_trigger'
declared inside parameter list
  int (*set_trigger_state)(struct iio_trigger *trig, bool state);

include/linux/iio/trigger.h:38:18: warning: 'struct iio_dev'
declared inside parameter list
           struct iio_dev *indio_dev);

'struct iio_dev' and 'struct iio_trigger' was used before declaration,
forward declaration for these structs to fix warning.
Signed-off-by: NPengyu Ma <pengyu.ma@windriver.com>
Acked-by: NDaniel Baluta <daniel.baluta@intel.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      ad30bad3
  25. 03 8月, 2015 2 次提交
  27. 24 7月, 2015 1 次提交
  29. 05 7月, 2015 1 次提交
  31. 01 6月, 2015 1 次提交
    • L
      iio: Specify supported modes for buffers · 225d59ad
      由 Lars-Peter Clausen 提交于 
      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: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      225d59ad
  33. 17 5月, 2015 1 次提交
  35. 11 5月, 2015 1 次提交
  37. 09 4月, 2015 1 次提交
  39. 29 3月, 2015 2 次提交
    • O
      iio: add support for hardware fifo · f4f4673b
      由 Octavian Purdila 提交于 
      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: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      f4f4673b
    • J
      iio: add watermark logic to iio read and poll · 37d34556
      由 Josselin Costanzi 提交于 
      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 <yannick.bedhomme@mobile-devices.fr>
Signed-off-by: NJosselin Costanzi <josselin.costanzi@mobile-devices.fr>
[rebased and remove buffer timeout]
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      37d34556
  41. 28 3月, 2015 1 次提交
  43. 15 2月, 2015 1 次提交
  45. 30 1月, 2015 2 次提交
  47. 28 1月, 2015 6 次提交
  49. 26 1月, 2015 1 次提交
  51. 26 12月, 2014 2 次提交
  53. 12 12月, 2014 1 次提交