Re: [PATCH RFC] hwspinlock: Don't take software spinlock before hwspinlock

[Ohad Ben-Cohen]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/