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

[Liam Girdwood <lrg@ti.com>]

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