On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote:
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?
I agree, that it opens up a possiblity that user may sleep after holding
a hw spinlock. But really, why should it prevents us from using it as a
hw mutex, if the need is legitimate?
We could make a check that the caller with NO_LOCK option calls only
with irq disabled, if thats required.
Thanks for the review.
-- Lina
--
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
