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

Reply via email to