Originally, commit 1a3dfad3 ("fix(bhi160): Fix interrupt behavior
during initialization") was supposed to fix the BHI160 axis-mapping
issue (see card10/firmware#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: https://git.card10.badge.events.ccc.de/card10/firmware/issues/133


Signed-off-by: Rahix <rahix@rahix.de>

The first epic_ws2812_write() call will set the first pixel to 0x008000
(bright green).  This is caused by the GPIO line being pulled down on
mode-setting (epic_gpio_set_pin_mode).  Wait before writing the values
to reset the bus and thus properly set the pixels to the correct colors
on first write.

Signed-off-by: Rahix <rahix@rahix.de>

If initialization fails, bhi160 API calls should not infinitely block
waiting for it to complete; they should fail immediately with an error
stating that something went wrong.

Add a flag that indicates the driver to not accept API requests because
initialization was not finished properly.

Signed-off-by: Rahix <rahix@rahix.de>

As discussed in issue card10/firmware#133, the BHI160 changes its
interrupt behavior during initialization.  In commit 2f56ff36
("fix(bhi160): Call bhy_mapping_matrix_set twice for the first time")
a quick workaround for this issue was added.  Replace this hack with
a proper fix by reconfiguring the interrupt on the host side according
to the specification.

(Finally) fixes card10/firmware#133.

Fixes: 2f56ff36 ("fix(bhi160): Call bhy_mapping_matrix_set twice for the first time")
Link: https://git.card10.badge.events.ccc.de/card10/firmware/issues/133#note_5894


Signed-off-by: Rahix <rahix@rahix.de>

Port the bhi160 mutex and hwlock usage in bhi.c to the new mutex API.
This will hopefully increase system stability.

Signed-off-by: Rahix <rahix@rahix.de>

The call to MAX77650_getDebounceStatusnEN0() in epic_buttons_read()
performs transactions on the I2C bus but is not guarded by locking the
I2C hwlock.  This leads to strange issues like USB mode deadlocking when
writing large files.

Widen the hwlock I2C section to encompass the MAX77650_getDebounceStatusnEN0()
call as well.  This fixes #189.

Signed-off-by: Rahix <rahix@rahix.de>

Port the buttons module to the new hardware lock API which can no longer
fail.

Signed-off-by: Rahix <rahix@rahix.de>

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 <rahix@rahix.de>

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: Rahix <rahix@rahix.de>

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 <rahix@rahix.de>

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 <rahix@rahix.de>

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 <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

By passing `&resched` instead of just `resched`, the internal comparison
in FreeRTOS would always evaluate to rescheduling.  Curiously, only some
GCC versions emit the -Waddress warning for this while others do not ...

Signed-off-by: Rahix <rahix@rahix.de>

Fix sign-compare warnings for these constants.

Signed-off-by: Rahix <rahix@rahix.de>

Fix all warnings in epicardium/modules.

Signed-off-by: Rahix <rahix@rahix.de>

Make the length parameter a `size_t` instead of a `intptr_t`.  A signed
value does not make any sense here and just leads to weird behavior if a
negative value is given nonetheless.

See issue card10/firmware#192

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>

As opposed to defining all possible keys at compile time.

In preparation for next commit

Mostly changing things like if { ... return} else { ... } to not have
an extra indentation level of the else part.

The diff is probably very weird even with stripped whitespace.

Fix the display backlight staying off while the pmic task prints its
messages (power-off/sleep & battery critial).

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability.

Additionally, fix a bug in `lifecycle.c:do_load()` where the function
would return without unlocking the API mutex if `hardware_reset()`
returns an error.

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability of the module.

Signed-off-by: Rahix <rahix@rahix.de>

Using a bare FreeRTOS mutex is deprecated.  Replace it with the new
`struct mutex`.  This should increase stability of the module.

Signed-off-by: Rahix <rahix@rahix.de>

In the current firmware, different locking mechanisms a littered around
the code-base.  Among them are bare FreeRTOS mutexes and the hw-locks.
The callers for these often specify timeouts but don't make much effort
in A) picking robust values for the timeout and B) recovering gracefully
from a timeout happening.  Most of the time, we return -EBUSY to _Python
code_.  This is really really bad API design.  The firmware needs to
have enough integrity to ensure these situations can't ever occur.

To combat this, add a new locking primitive: The `struct mutex`.  The
intention is to replace all other locking and synchronization APIs with
this one.  This will provide one central place to debug any sort of
locking issues.

The `struct mutex` API is based on a few assumptions about locking.
Those are detailed in `Documentation/epicardium/mutex.rst`, which is
part of this commit.  The most important one is:

    Locking can **never** fail.

By requiring this to be true, we eliminate the need for drivers to
contain (often incorrect) logic for dealing with locking fails.  This
should drastically improve the stability of the firmware in regards to
lock-related bugs.

This commit does not introduce any functional changes yet.

Signed-off-by: Rahix <rahix@rahix.de>

Signed-off-by: Rahix <rahix@rahix.de>