• Rahix's avatar
    feat(epicardium): Add a proper mutex implementation · 9a5a46cd
    Rahix authored
    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's avatarRahix <rahix@rahix.de>
index.rst 1.65 KB