On Mon, Mar 05, 2012 at 02:48:02PM +0000, Liam Girdwood wrote:
A separate DAPM mutex and subclass (for init and PCM ops) would be required here but I'm fine with that too.
What's the path where init and PCM ops end up fighting with each other for DAPM? I can't think of one right now.
I do also need the card mutex changes for Dynamic PCM though since we need to lock the card PCM operations for Dynamic PCM devices.
Yes, they do need to have something.
Fwiw, looking at mutex holders in soc/codecs/ gives us :-
grep -rn "mutex_lock(" sound/soc/codecs/
sound/soc/codecs/twl6040.c:686: mutex_lock(&priv->mutex);
Some of which initially look like private mutexs.
Yes, we only really need to worry about the ones that are taking a subsystem level mutex here - if they're locking a driver-local mutex they shouldn't need to worry about what the subsystem does.
The twl6040 one looks like it doesn't work anyway as we're only taking the lock at one point which is itself guaranteed to be called only from one context.