On Mon, May 11, 2015 at 5:46 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: > On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote: >> On Fri, May 1, 2015 at 8:07 PM, Lina Iyer <lina.iyer@xxxxxxxxxx> wrote: >> 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. > > 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? If we want hw mutex functionality, let's discuss how to expose it. Exposing it using the existing hw spinlock API might not be ideal, as users might get confused. Additionally, there are hardware IP locking blocks out there which encourage users to sleep while waiting for a lock, by providing interrupt functionality to wake them up when the lock is freed. So if we choose to add a hw mutex API it might be used by others in the future too (though this reason alone is not why we would choose to add it now of course). API discussions aside, what do you want to happen in your scenario while the lock is taken? are you OK with other users spinning on the lock waiting for it to be released? IIUC that might mean processors spinning for a non-negligible period of time? 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
