On Fri, Nov 05, 2010 at 09:53:35AM +0200, Peter Ujfalusi wrote:
Well, I think if we want to have one place to use a lock, this is the highest we can go.
This assumes that we've figured out the correct thing to lock and where we need to hold it - if you want to lock the DAPM algorithm then that's one thing, but it's not clear to me that this is the only thing we need to lock or if we need to ensure that the users of DAPM are handled and therefore this level of stuff becomes redundant.
All other places, when dapm_power_widgets called are protected by codec->mutex so those paths are safe. By replacing the custom kcontrol/callbacks with SOC_DAPM_PIN_SWITCH() the problem is gone. So it seams that my case can be solved easily with the SOC_DAPM_PIN_SWITCH(), but the race remains, and other setups might fail under some rare scenario
This is all smelling like we should be doing something to ensure that all the controls take the CODEC lock. We're relying pretty heavily on that throughout the code so there's going to be other smoking guns there.
It might be a good idea to go through the machine drivers, and check for snd_soc_dapm_sync usage.
I think so; probably any DAPM function has this issue.