[PATCH 3/3] omap: add hwspinlock device

[Ohad Ben-Cohen]

On Fri, Oct 22, 2010 at 11:59 AM, Kamoolkar, Mugdha <mugdha at ti.com> wrote:
>> From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
>> I agree.
>>
>> But we seem to have this sort of problem anyway:
>>
...
> That is true. Perhaps we should consider adding a software
> implementation over HW spinlocks.

Yes, this is probably inevitable.

It would also be useful for the user space implementation of TI's
RingIO and FrameQueue protocols coming in Syslink 3.0, which will also
not be able to directly use the hwspinlock because of the same
reasons.

This layer would maintain the owner of each (virtual) lock in a
non-cacheable shared memory entry, together with the id of the
hwspinlock that would protect that 'owner' entry.

This way we no longer need to use predefined hwspinlocks (the id of
the hwspinlock is announced in the shared memory entry). So we can
ditch the _request_specific() API, and we can move to arch_initcall
(just to beat the current race with i2c-omap).

> We were anyway considering doing this,
> because the number of hw spinlocks available for our usage are not
> sufficient when we look at multi-channel use-cases.

Sure, this layer can provide any number of locks over a single
hwspinlock (with the obvious price of hwspinlock contention).