Re: [PATCH 2/3] ASoC: dapm - Use card mutex for DAPM ops instead of codec mutex.

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --]

On Mon, Mar 05, 2012 at 05:05:12PM +0000, Liam Girdwood wrote:
> On Mon, 2012-03-05 at 16:45 +0000, Mark Brown wrote:

> > control_rwsem isn't in mainline...

> Sorry, my typo controls_rwsem. Mostly used in sound/core/control.c

Oh, ick.  Right.  This is a bit nasty.  So, the ALSA core is assuming
that we won't lock against ourselves during probe, which is actually not
that unreasonable given that the driver model guarantees that probe
isn't going to get called multiple times.  Now, if Grant's probe
deferral stuff makes it in to 3.4 (which would be nice anyway and is
looking likely) we can actually pretty much do that as the driver core
will do the waiting for things to come up bit for us which is the main
thing we're worried about here.

That said there are cases where we want to do a DAPM run due to
interrupts.  Currently we're actually just suppressing all those DAPM
runs so perhaps we'd be home free, we'd just need to worry about widget
status updates and that's much more localised.  But let's just add the
nested mutex for now (well, I guess for 3.5 at this point - Linus is
threatening to open the merge window this week so probably shouldn't be
pushing much new stuff in now) and take another look later.

The other nicer thing to do would be to fix this at an ALSA level - the
controls_rwsem looks like a good candidate for something like RCU, it's
a read mostly list with very infrequent updates so even a rwsem is more
heavyweight than we need.  The index offset stuff does make things very
slightly more complex though I think it's tractable.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]