1. 20 Jan, 2020 2 commits
  2. 09 Jan, 2020 1 commit
  3. 05 Jan, 2020 1 commit
  4. 04 Jan, 2020 1 commit
  5. 03 Jan, 2020 3 commits
  6. 02 Jan, 2020 1 commit
  7. 31 Dec, 2019 1 commit
    • Rahix's avatar
      revert(bhi160): Re-add hack to fix axis mapping · 448ec494
      Rahix authored
      Originally, commit 1a3dfad3 ("fix(bhi160): Fix interrupt behavior
      during initialization") was supposed to fix the BHI160 axis-mapping
      issue (see #133) but apparently on some devices it still
      needs the original hack to work.  Revert the removal of the axis-mapping
      hack from commit 2f56ff36 ("fix(bhi160): Call bhy_mapping_matrix_set
      twice for the first time").
      Fixes: 1a3dfad3 ("fix(bhi160): Fix interrupt behavior during initialization")
      Link: #133
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
  8. 30 Dec, 2019 2 commits
  9. 29 Dec, 2019 14 commits
  10. 28 Dec, 2019 3 commits
  11. 26 Dec, 2019 2 commits
  12. 22 Dec, 2019 6 commits
    • Rahix's avatar
      Merge 'Port hardware locks to new mutex API' · b46a9e7a
      Rahix authored
      Move hw-locks to new mutex API in multiple steps to keep diffs readable.  The
      users of hw-locks are **not** ported to the new-semantics; this needs to be
      done as a follow up.  One patch is included, porting the MAX30001 driver in
      commit 6da4644e ("chore(max30001): Port to new mutex and hw-lock APIs").
      See merge request card10/firmware!356
    • Rahix's avatar
      chore(max30001): Port to new mutex and hw-lock APIs · 6da4644e
      Rahix authored
      Using a FreeRTOS mutex directly is deprecated.  Replace it with a
      `struct mutex`.  Similarly, the deprecated `hwlock_acquire_timeout()`
      is replaced with `hwlock_acquire()`.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      feat(hw-locks): Introduce new hw-lock API · 605d5e56
      Rahix authored
      Re-add a `hwlock_acquire()` method, but this time without a timeout
      parameter.  From a functional point of view, this is just a wrapper
      around `mutex_lock()`.
      Additionally, add `hwlock_acquire_nonblock()` which behaves like
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      chore(hw-locks): Rename to hwlock_acquire_timeout · 610a3048
      Rahix authored
      Rename hwlock_acquire() to hwlock_acquire_timeout() in preparation for
      future changes to the hw-lock API.  Change all uses of the hw-lock API
      to reflect this change.
      This commit does not introduce any functional changes, except getting
      rid of the timeout usage warnings.  This change is no-op, because the
      hwlock_acquire() implementation already replaces any non-zero timeout
      value with portMAX_DELAY.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      feat(hw-locks): hwlock_release() should return void · 18202736
      Rahix authored
      With the switch to the new mutex API, hwlock_release() cannot fail under
      any circumstances.  To emphasize this, make it return void instead of
      int (Previously it just always returned 0).
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
    • Rahix's avatar
      feat(hw-locks): Switch to new mutex API · d93c7f00
      Rahix authored
      Reimplement the hw-lock module to use the new mutex API.  This slightly
      changes the semantics of locking a hw-lock as the new mutex API does not
      allow timeouts.  When a hwlock_acquire() with a (non-infinite) timeout
      is attempted, a warning is printed to the serial console.
      Additionally, instead of returning -EINVAL on use of a non-existent
      hardware lock, the new implementation triggers a firmware panic.
      Signed-off-by: Rahix's avatarRahix <rahix@rahix.de>
  13. 21 Dec, 2019 1 commit
  14. 10 Dec, 2019 1 commit
  15. 09 Dec, 2019 1 commit