• Dave Martin's avatar
    ARM: mcpm: Add baremetal voting mutexes · 9762f12d
    Dave Martin authored
    
    
    This patch adds a simple low-level voting mutex implementation
    to be used to arbitrate during first man selection when no load/store
    exclusive instructions are usable.
    
    For want of a better name, these are called "vlocks".  (I was
    tempted to call them ballot locks, but "block" is way too confusing
    an abbreviation...)
    
    There is no function to wait for the lock to be released, and no
    vlock_lock() function since we don't need these at the moment.
    These could straightforwardly be added if vlocks get used for other
    purposes.
    
    For architectural correctness even Strongly-Ordered memory accesses
    require barriers in order to guarantee that multiple CPUs have a
    coherent view of the ordering of memory accesses.  Whether or not
    this matters depends on hardware implementation details of the
    memory system.  Since the purpose of this code is to provide a clean,
    generic locking mechanism with no platform-specific dependencies the
    barriers should be present to avoid unpleasant surprises on future
    platforms.
    
    Note:
    
      * When taking the lock, we don't care about implicit background
        memory operations and other signalling which may be pending,
        because those are not part of the critical section anyway.
    
        A DMB is sufficient to ensure correctly observed ordering if
        the explicit memory accesses in vlock_trylock.
    
      * No barrier is required after checking the election result,
        because the result is determined by the store to
        VLOCK_OWNER_OFFSET and is already globally observed due to the
        barriers in voting_end.  This means that global agreement on
        the winner is guaranteed, even before the winner is known
        locally.
    
    Signed-off-by: default avatarDave Martin <dave.martin@linaro.org>
    Signed-off-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
    Reviewed-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
    Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
    9762f12d