Hi Lina, On Fri, May 1, 2015 at 8:07 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: > Some uses of the hwspinlock could be that one entity acquires the lock > and the other entity releases the lock. This allows for a serialized > traversal path from the locking entity to the other. > > For example, the cpuidle entry from Linux to the firmware to power down > the core, can be serialized across the context switch by locking the > hwspinlock in Linux and releasing it in the firmware. > > Do not force the caller of __hwspin_trylock() to acquire a kernel > spinlock before acquiring the hwspinlock. Let's discuss whether we really want to expose this functionality under the same hwspinlock API or not. In this new mode, unlike previously, users will now be able to sleep after taking the lock, and others trying to take the lock might poll the hardware for a long period of time without the ability to sleep while waiting for the lock. It almost sounds like you were looking for some hwmutex functionality. What do you think about this? Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
