[alsa-devel] [PATCH - try2] ASoC: TPA6130A2 amplifier driver

[ext-Eero.Nurkkala at nokia.com]

ext Mark Brown wrote:
> On Fri, Oct 09, 2009 at 04:36:16PM +0300, Peter Ujfalusi wrote:
> 
>> Well it is very unlikely that something like this could ever happen since the
>> tpa6130a2_channel_enable and the tpa6130a2_power is called when DAPM is
>> enabling/disabling the path. I think in a middle of enable or disable there
>> should not be any opposite operation running in DAPM...
> 
> DAPM guarantees single threadedness - DAPM itself would get confused if
> there were more than one power update in progress at once.

I guess there's (or may be) an exception though. I think I've seen some
strangeness with the close_delayed_work() -> and simultaneous mixer tweaking:

http://mailman.alsa-project.org/pipermail/alsa-devel/2009-October/021671.html

This is just an example:

Userspace thread:
snd_soc_dapm_put_volsw() ->
mutex_lock(&widget->codec->mutex); ->
dapm_mixer_update_power() ->
dapm_power_widgets() -> PRE_EMTED in damp_power_widgets()

Workqueue thread:
close_delayed_work()
snd_soc_dapm_stream_event()
mutex_lock(&widget->codec->mutex);
mutex_unlock(&widget->codec->mutex);
dapm_power_widgets() -> PRE_EMTED back to Userspace thread

So there can and does run two dapm_power_widgets() when stars
point to the right direction. That's when delayed work is at
damp_power_widgets, and then preempted to
the userspace thread.  May that isn't related to this TPA though, but
I think I'll silently review the code so that the "stars are forced to
point to the right direction".

(but yeah, these are just my observations, don't worry about them)