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

[Shawn Guo]

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
1a0

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

-- 
Regards,
Shawn