On Friday 07 October 2011 12:47:49 Mark Brown wrote:
Removing the calls is a totally sensible thing to do, like I say they should at best be a waste of time. The problem with your patch was that weren't just removing them, you were replacing them with calls to new_widgets() which should be equally pointless. If we have to do that we're clearly failing at something.
I tend to agree with all of these. I have done some bisecting, and this is my conclusion: We have quite many machine drivers adding their DAPM widgets/routes in their dai_link->init callback. All of these machine driver added DAPM widgets stopped working with:
commit 0b07ab9244d34929b6e07d6a275137a229e9c839 ASoC: Instantiate DAPM widgets before we do the DAI link init
This patch moves the snd_soc_dapm_new_widgets() call pre dai_link->init. Make sense for those machines which passing their DAPM widgets/routes via the snd_soc_card struct. Rest of the machines were ended up their DAPM widgets being not initialized - ever. They had the soc_dapm_sync call which is pointless thing to call anyway. These machines started to crash with commit:
commit 35c64bcad5c8244d973efbf7e58f6e0e09635504 ASoC: Ensure all DAPM widgets have a power check callback
Since the check for w->power_check has been removed from dapm_power_one_widget
What we can do: - Add back the snd_soc_dapm_new_widgets() call post dai_link->init in the soc_post_component_init (while keeping the pre dai_link->init call to this). - Convert all machine drivers which uses the dai_link->init call to just add their DAPM widgets/routes to pass it via snd_soc_card struct. - From the remaining drivers the soc_dapm_sync need to be removed. If they do funky stuff with their widgets we might need to add snd_soc_dapm_new_widgets() for their init call to be sure they are not crashing.
I have converted some of the OMAP machine drivers according to point 2 after this patch. I only changed those which seamed obvious.
This patch was mostly a search'n'replace to make sure they are no longer crashing.
-- Péter