[alsa-devel] [PATCH 2/2] ASoC: DAPM - Make sure DAPM widget IO ops hold the component mutex.

Shawn Guo shawn.guo at linaro.org
Mon Mar 12 10:12:08 CET 2012

On Sun, Mar 11, 2012 at 12:55:59PM +0000, Mark Brown wrote:
> On Fri, Mar 09, 2012 at 01:11:26PM -0600, Timur Tabi wrote:
> > Liam Girdwood wrote:
> > > Can you switch on the mutex debugging kernel config here.  I've just had
> > > a quick look and the WM8776 and its not holding the codec mutex or
> > > calling snd_soc_update_bits_locked() so it must deadlock via another
> > > path.
> > Enabling the debug options didn't reveal anything, unfortunately.
> The major difference between your two boards is that CS4270 doesn't use
> DAPM while WM8776 does.  Though if one of them were going to break I'd
> really expect it to be the CS4270, obviously non-DAPM CODECs are a real
> corner case (to the point where I think you're the only active user of
> such a device) and certainly all Liam's TI reference systems have DAPM
> CODECs so this is really surprising...  I wonder if PowerPC mutexes are
> less forgiving here?

I'm not sure this is PowerPC specific.  I'm running ARM platform and
seeing this commit also breaks my imx-sgtl5000 (SGTL5000 codec) driver
that I'm submitting.

[ INFO: possible recursive locking detected ]
3.3.0-rc4+ #159 Not tainted
aplay/395 is trying to acquire lock:
 (&codec->mutex){+.+...}, at: [<802f7414>] soc_widget_update_bits_locked+0x88/0x

but task is already holding lock:
 (&codec->mutex){+.+...}, at: [<802f9df4>] snd_soc_dapm_stream_event+0x38/0xc0


More information about the Alsa-devel mailing list