Skip to content
Snippets Groups Projects
  1. Jan 03, 2020
  2. Jan 02, 2020
  3. Dec 31, 2019
  4. Dec 30, 2019
  5. Dec 29, 2019
  6. Dec 28, 2019
  7. Dec 26, 2019
  8. Dec 22, 2019
    • 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
      b46a9e7a
    • 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: default avatarRahix <rahix@rahix.de>
      6da4644e
    • 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
      `mutex_trylock()`.
      
      Signed-off-by: default avatarRahix <rahix@rahix.de>
      605d5e56
    • 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: default avatarRahix <rahix@rahix.de>
      610a3048
    • 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: default avatarRahix <rahix@rahix.de>
      18202736
    • 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: default avatarRahix <rahix@rahix.de>
      d93c7f00
  9. Dec 21, 2019
  10. Dec 10, 2019
  11. Dec 09, 2019
Loading