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?
- Dave
--
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
