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?