1. 17 Feb, 2018 1 commit
  2. 08 Jan, 2018 1 commit
  3. 02 Mar, 2017 1 commit
  4. 10 Jan, 2017 6 commits
  5. 24 Sep, 2016 1 commit
  6. 05 Sep, 2016 1 commit
  7. 21 Aug, 2016 1 commit
    • Brian Norris's avatar
      iio: fix sched WARNING "do not call blocking ops when !TASK_RUNNING" · fcf68f3c
      Brian Norris authored
      When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out
      that we're calling sleeping primitives within the wait_event loop, which
      means we might clobber the task state:
      
      [   10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffc00026b610>]
      [   10.845531] ------------[ cut here ]------------
      [   10.850161] WARNING: at kernel/sched/core.c:7630
      ...
      [   12.164333] ---[ end trace 45409966a9a76438 ]---
      [   12.168942] Call trace:
      [   12.171391] [<ffffffc00024ed44>] __might_sleep+0x64/0x90
      [   12.176699] [<ffffffc000954774>] mutex_lock_nested+0x50/0x3fc
      [   12.182440] [<ffffffc0007b9424>] iio_kfifo_buf_data_available+0x28/0x4c
      [   12.189043] [<ffffffc0007b76ac>] iio_buffer_ready+0x60/0xe0
      [   12.194608] [<ffffffc0007b7834>] iio_buffer_read_first_n_outer+0x108/0x1a8
      [   12.201474] [<ffffffc000370d48>] __vfs_read+0x58/0x114
      [   12.206606] [<ffffffc000371740>] vfs_read+0x94/0x118
      [   12.211564] [<ffffffc0003720f8>] SyS_read+0x64/0xb4
      [   12.216436] [<ffffffc000203cb4>] el0_svc_naked+0x24/0x28
      
      To avoid this, we should (a la https://lwn.net/Articles/628628/) use the
      wait_woken() function, which avoids the nested sleeping while still
      handling races between waiting / wake-events.
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Reviewed-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Cc: <Stable@vger.kernel.org> # 3.19+ for introduction of wake_woken
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      fcf68f3c
  8. 28 Mar, 2016 1 commit
    • Irina Tirdea's avatar
      iio: fix config watermark initial value · 1bef2c1d
      Irina Tirdea authored
      config structure is set to 0 when updating the buffers, so by
      default config->watermark will be 0. When computing the minimum
      between config->watermark and the buffer->watermark or
      insert_buffer-watermark, this will always be 0 regardless of the
      value set by the user for the buffer.
      
      Set as initial value for config->watermark the maximum allowed
      value so that the minimum value will always be set from one of the
      buffers.
      Signed-off-by: default avatarIrina Tirdea <irina.tirdea@intel.com>
      Fixes: f0566c0c ("iio: Set device watermark based on watermark of all
      attached buffers")
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      1bef2c1d
  9. 06 Feb, 2016 1 commit
  10. 21 Nov, 2015 1 commit
  11. 25 Oct, 2015 4 commits
  12. 12 Aug, 2015 1 commit
  13. 02 Aug, 2015 1 commit
  14. 21 Jun, 2015 1 commit
  15. 01 Jun, 2015 4 commits
  16. 23 May, 2015 3 commits
    • Lars-Peter Clausen's avatar
      iio: __iio_update_buffers: Leave device in sane state on error · 1250186a
      Lars-Peter Clausen authored
      Currently when something goes wrong at some step when disabling the buffers
      we immediately abort. This has the effect that the enable/disable calls are
      no longer balanced. So make sure that even if one step in the disable
      sequence fails the other steps are still executed.
      
      The other issue is that when either enable or disable fails buffers that
      were active at that time stay active while the device itself is disabled.
      This leaves things in a inconsistent state and can cause unbalanced
      enable/disable calls. Furthermore when enable fails we restore the old scan
      mask, but still keeps things disabled.
      
      Given that verification of the configuration was performed earlier and it
      is valid at the point where we try to enable/disable the most likely reason
      of failure is a communication failure with the device or maybe a
      out-of-memory situation. There is not really a good recovery strategy in
      such a case, so it makes sense to leave the device disabled, but we should
      still leave it in a consistent state.
      
      What the patch does if disable/enable fails is to deactivate all buffers
      and make sure that the device will be in the same state as if all buffers
      had been manually disabled.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      1250186a
    • Lars-Peter Clausen's avatar
      iio: __iio_update_buffers: Split enable and disable path into helper functions · 623d74e3
      Lars-Peter Clausen authored
      __iio_update_buffers is already a rather large function with many different
      error paths and it is going to get even larger. This patch factors out the
      device enable and device disable paths into separate helper functions.
      
      The patch also re-implements iio_disable_all_buffers() using the new
      iio_disable_buffers() function removing a fair bit of redundant code.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      623d74e3
    • Lars-Peter Clausen's avatar
      iio: __iio_update_buffers: Verify configuration before starting to apply it · 6e509c4d
      Lars-Peter Clausen authored
      Currently __iio_update_buffers() verifies whether the new configuration
      will work in the middle of the update sequence. This means if the new
      configuration is invalid we need to rollback the changes already made. This
      patch moves the validation of the new configuration at the beginning of
      __iio_update_buffers() and will not start to make any changes if the new
      configuration is invalid.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      6e509c4d
  17. 17 May, 2015 3 commits
  18. 29 Mar, 2015 2 commits
    • Octavian Purdila's avatar
      iio: add support for hardware fifo · f4f4673b
      Octavian Purdila authored
      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: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Reviewed-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      f4f4673b
    • Josselin Costanzi's avatar
      iio: add watermark logic to iio read and poll · 37d34556
      Josselin Costanzi authored
      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: default avatarJosselin Costanzi <josselin.costanzi@mobile-devices.fr>
      [rebased and remove buffer timeout]
      Signed-off-by: default avatarOctavian Purdila <octavian.purdila@intel.com>
      Reviewed-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      37d34556
  19. 04 Feb, 2015 1 commit
  20. 25 Jan, 2015 1 commit
  21. 05 Jan, 2015 1 commit
  22. 12 Dec, 2014 3 commits