* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [090128 11:27]: > On Wed, Jan 28, 2009 at 10:24:22AM -0800, Tony Lindgren wrote: > > From: Stanley.Miao <stanley.miao@xxxxxxxxxxxxx> > > > > A spin_lock deadlock will occur when omap_mcbsp_request() is invoked. > > > > omap_mcbsp_request() > > \- clk_enable(mcbsp->clk) [takes and holds clockfw_lock] > > \- omap2_clk_enable() > > \- _omap2_clk_enable() > > \- omap_mcbsp_clk_enable() > > \- clk_enable(child clock) [tries for clockfw_lock again] > > > > mcbsp_clk is a virtual clock and it comprises several child clocks. when > > enable mcbsp_clk in omap_mcbsp_request(), the enable function of mcbsp_clk > > will enable its child clocks, then the deadlock occurs. > > I'm debating about this. On one hand, it looks like this has been like > this for approaching six months, so what's a few more months to wait > for the clkdev stuff. Yeah that's why we've been going back and forth with this on the linux-omap list. > On the other hand, we probably need this fix. The question is, are there > real problems being caused by this, or is this patch just the result of > code analysis? And can these problems be produced with mainline (iow, > do we have enough other code merged to expose this)? AFAIK it happens in the mainline with CONFIG_PREMEPT and ASoC. Tony -- 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
