On Fri, Mar 09, 2012 at 03:28:22PM +0800, Shawn Guo wrote:
On 9 March 2012 15:13, Shawn Guo shawn.guo@linaro.org wrote:
On Fri, Mar 09, 2012 at 02:11:41AM +0000, Tabi Timur-B04825 wrote:
Shawn Guo wrote:
Are you testing the patch set on top of the SHA below, which I mentioned in the cover letter?
3030763 (Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into topic/asoc)
Adding Liam who I just noticed isn't on the CCs.
It appears the problem is with for-3.4 itself. I'm running git-bisect now to narrow it down.
My bisect tells that the offending commit is:
96acc35 (ASoC: DAPM: Make sure DAPM widget IO ops hold the component mutex)
But I do not understand why yet.
============================================= [ 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
Ick, right. We need to create that separate I/O mutex I think... Perhaps we should punt the locking change until 3.5 too, there's no non-CODEC DAPM in 3.4?