On Thu, 2009-10-01 at 14:09 +0200, ext Mark Brown wrote:
On Thu, Oct 01, 2009 at 02:56:24PM +0300, Eero Nurkkala wrote:
Actually, in this case: (kernel 2.6.28)
That's rather old...
Yes, but I've been mirroring things with 2.6.31..
But if it didn't come from snd_soc_dapm_put_volsw(), but instead: close_delayed_work() -> snd_soc_dapm_stream_event() -> dapm_power_widgets() -> dapm_set_pga() then the codec->mutex is not taken, and the bug presented in the patch is out there, no?
Right, so close_delayed_work() needs to lock the card while it runs.
Can't really do that, because snd_soc_dapm_stream_event() will try to take codec mutex again. Tried the following:
--- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2071,9 +2071,9 @@ int snd_soc_dapm_stream_event(struct snd_soc_codec *codec, } } } - mutex_unlock(&codec->mutex);
dapm_power_widgets(codec, event); + mutex_unlock(&codec->mutex); dump_dapm(codec, __func__); return 0; }
Does that make any sense?
- Eero