On Wednesday 28 October 2009 08:53:34 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote: > Yeah, maybe I took the SMP safeness into play without looking any code, > my bad =) I was remembering a different version of this McBSP thing, now > that I looked into it, it looked different. > > Right, I reviewed the code, and it was first looking really bad at > sound/soc/omap/omap-mcbsp.c, where it calls omap_mcbsp_get_dma_op_mode() > from different places. However, it's not an issue because in: > arch/arm/plat-omap/mcbsp.c : dma_op_mode_store(), > the dma_op_mode is written only if the mcbsp is unoccupied. So it is SMP > safe. > > ..and a single read is always atomic, so this is buggy code: > > 301 spin_lock_irq(&mcbsp->lock); > 302 dma_op_mode = mcbsp->dma_op_mode; > 303 spin_unlock_irq(&mcbsp->lock); > 304 > 305 return dma_op_mode; > > The spinlocks are unnecessary. In the above example, you get the same > with just "return mcbsp->dma_op_mode;" > > -> Peter's patch is a good cleanup.
Jarkko: are we going to take this? -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
