On Mon, Oct 06, 2008 at 11:01:53AM -0700, David Brownell wrote:
> On Monday 06 October 2008, Paul Walmsley wrote:
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.27-rc8-omap1 #174
> > > ---------------------------------------------
> > > aplay/1816 is trying to acquire lock:
> > > (clockfw_lock){....}, at: [<c0036be4>] clk_enable+0x24/0x70
> > >
> > > but task is already holding lock:
> > > (clockfw_lock){....}, at: [<c0036be4>] clk_enable+0x24/0x70
> >
> > Yeah, the code that's in that driver is broken. The driver
> > sets up a custom clk_enable() function that calls clk_enable() again. And
> > clk_enable() takes clockfw_lock.
>
> I don't follow. Could you point at those lines of code?
> The only clkfw_lock I see is in plat-omap/clock.c code ...
> which isn't part of this ASoC driver or even its board glue.
>
>
> > The omap_clk_associate() code should resolve this problem.
>
> Time to resolve that, then... are you saying that the patches
> Felipe posted will, if merged, make this lockdep report go
> away so it's safe to run lockdep and ALSA on twl4030 codecs?
heh, I'll repost tomorrow changing the name to omap_clk_associate()
--
balbi
--
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
