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