On Tuesday 18 January 2011 14:08:51 ext Peter Ujfalusi wrote:
Resend, since alsa-devel address was mistyped ;)
On 01/18/11 13:39, ext Mark Brown wrote:
I *suspect* that we're in a similar case and either the locking has been broken by the multi-component stuff or there's other cases that need protection, probably the jack detection code.
The snd_soc_dapm_sync is just a wrapper for dapm_power_widgets, right? It (snd_soc_dapm_sync) is used in soc-core:soc_post_component_init. But there is no need for it, since the snd_soc_dapm_new_widgets will call dapm_power_widgets at the end. so we can remove the snd_soc_dapm_sync from there. For the rest: I would replace the snd_soc_dapm_sync calls in soc-dapm.c with dapm_power_widgets(dapm, SND_SOC_DAPM_STREAM_NOP); calls. Modify the snd_soc_dapm_sync to use the codec->mutex around the dapm_power_widgets call. In that way I think all race conditions going to be covered without adding new mutex.
What do you think? I can make a patch...
Or not.. soc-jack.c:snd_soc_jack_report also calls snd_soc_dapm_sync, while keeping the codec->mutex locked... Should machine drivers also take the mutex when they call snd_soc_dapm_sync?