On Fri, 5 Jun 2009, Woodruff, Richard wrote: > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley > > Sent: Friday, June 05, 2009 4:26 PM > > > On Thu, 28 May 2009, Rajendra Nayak wrote: > > > > > This patch implements locking using the semaphore in scratchpad > > > memory preventing any concurrent access to scratchpad from OMAP > > > and Baseband/Modem processor. > > > > This patch might be okay for the target use case. But there might still > > be a race window with this patch, where the modem could steal the MPU's > > lock or vice versa. > > > > That swp tries to guarantee atomicity through exclusive memory accesses, > > but the AXI2OCP bridge section of the TRM claims that the bridge > > translates "exclusive accesses to non-exclusive read/write in the bridge" > > (section 3.2.3.2). That seems to suggest that the memory accesses will be > > non-atomic and that therefore a race window exists. > > This is an incorrect interpretation. A race does not exist because of this point. > > The AXI2OCP does translate external excusive operations this way > (STREX/LWREX). This is not the same for SWP. SWP generates a global > bus lock. > > Exclusive operations do have a reservation in the L2 block. So they are > good until they go to external memory. On OMAP these work as you expect > with respect to the ARM, but won't work between ARM and DSP or other > master. > > SWP on the other hand still works. SWP is a relative pig compared to > STREX/LWREX as it locks the whole L3, compared to a small key address, > but, it's a lot lighter than a mailbox. OK, thanks for the explanation, Richard. Sounds like it's okay then, - Paul -- 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
