Skip to content
Snippets Groups Projects

Port hardware locks to new mutex API

Merged Port hardware locks to new mutex API
rahix/hw-lock-new-mutex into master
Merged rahix requested to merge rahix/hw-lock-new-mutex into master
  1. Dec 22, 2019
    • 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