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. 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)? -- 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
