On Mon, 2012-03-12 at 17:12 +0800, Shawn Guo wrote:
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
Timur, Shawn, thanks for your debug.
snd_soc_dapm_stream_event() should not hold the codec mutex here. Something is out of sync between my branch and Mark's, maybe I've missed something out on a recent patch.
Liam