Re: [PATCH v3 0/4] Introduce hardware spinlock framework

[Ohad Ben-Cohen]

Hi Andrew,

On Sat, Dec 18, 2010 at 2:53 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Ohad Ben-Cohen <ohad@xxxxxxxxxx> [101216 13:34]:
>> Tony, Andrew, can you please have a look ?
>>
>> Any comment or suggestion is appreciated.
>
> Looks sane to me from omap point of view and it seems the locks
> are now all timeout based:
>
> Acked-by: Tony Lindgren <tony@xxxxxxxxxxx>

Can you please have a look at this patch set (see link no. [1] below) ?

Short summary:

This hwspinlock framework adds support for hardware-based locking
devices, needed to accomplish synchronization and mutual exclusion
operations between remote processors that have no alternative
mechanism to do so.

This patch set adds a framework and an OMAP implementation. It had
circulated several times in the relevant mailing lists, and all
comments were addressed. The third version of this patch set [1] was
submitted about a month ago and so far there is no outstanding
comment.

Users for this framework that we are aware of:

1. OMAP4 and Davinci Netra (DM8168): both of these SoC have the same
hwspinlock module and will share the same host implementation.

2. Other platforms (such as omap3530 and omapl1xx) that have no such
hardware support, but would still need to achieve synchronization (to
communicate with their DSP).

The only way to achieve mutual exclusion on those platforms is by
using a shared-memory synchronization algorithm called Peterson's
Algorithm [2].

We would still need the same hwspinlock framework for that - the busy
looping, the timeout, the various locking schemes, the lock resource
allocation - are all still valid. The only difference would be the
actual lock implementation, therefore we will add another host
implementation
for these platforms.

3. The C6474, a multi-core DSP device [3], have Linux running on one
of its cores, and hardware support for synchronization (btw the C6474
has a richer hardware module that would need more than the hwspinlock
framework offer today - it also supports queuing, owner semantics and
interrupt notification to let a processor know when it acquires a
lock, so it wouldn't have to spin..).  Disclaimer: it will probably
take some time until c6x support is merged upstream, but this is
something that is being actively worked on [4].


Any comment or suggestion is appreciated.

Thanks,
Ohad.

[1] http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg39833.html
[2] http://en.wikipedia.org/wiki/Peterson's_algorithm
[3] http://focus.ti.com/docs/prod/folders/print/tms320c6474.html
[4] http://www.linux-c6x.org/wiki/index.php/Main_Page
--
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/