Hi Mark Thank you for your feedback > > To avoid Sound Card crash in (2) case, what we can do now is, add dirty > > flag on Sound Card, and avoid to open Sound Card. > > This patch solved this issue. > > I think this is a good direction to at least start to mitigate these > problems (which we really should be doing) and hopefully make it easier > to do further improvements in future. There's obviously more places > where we should be checking the flag (controls for example) but they can > be added later. One thing I would like to see is instead of setting the > flag directly when we see a problem call a function to do it. That way > if we want to improve things in the future we can do that without having > to update the callers again. I guess you are pointing about snd_soc_dapm_shutdown() in snd_soc_unregister_card() ? If so, I agree. Actually, I don't like this kind of adhoc handling. I want to explain about it. Order [1] Disable Sound Card -> Disable CPU/Codec/Platform or do nothing [2] Disable CPU/Codec/Platform -> Disable Card or do nothing Operation 1) shutdown all Card connected DAPM 2) cleanup Card resource. In case of order [1], operation 1) -> 2) is no problem, because all card connected DAPM exists on Card. But, in case of order [2], operation 1) will try to call disconnected DAPM. The DAPM disconnection from Card is done by snd_soc_dapm_free() which is called from soc_remove_component(). This soc_remove_component() will be called with "remove_order" from operation 2). One note is that reordering operation to 2) -> 1) will avoid this crash issue, but it is no meaning, because 1) will do nothing ;) Here, other solution is calling soc_remove_component() without "remove_order" or calling snd_soc_dapm_free() when CPU/Codec/Platform are disabled. But, 1 bad-point is that disabled CPU/Codec/Platform have no chance to be called about snd_soc_dapm_set_bias_level() (= 1) operation). Of course, adhoc function can solve this issue too. If you are OK, I can work for this idea and remove adhoc operation from snd_soc_unregister_card() Best regards --- Kuninori Morimoto _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
