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.htm...
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)