[...]
But, I noticed it breaks set_fmt() and pcm_new() timing. Before: set_fmt -> pcm_new After: pcm_new -> set_fmt
My driver adds kctrl on pcm_new timing, and it refers set_fmt's settings. but now, set_fmt happen *after* pcm_new. (it adds new kctrl if it has SND_SOC_DAIFMT_CBS_CFS)
What does that control do? This seems to be a bit of a layering violation to create a control in the PCM driver based on the configuration of the DAI link.
My solution is these 2 pattern1) exchange set_fmt/pcm_new timing. see below pattern2) exchange kctrl assumption (always set kctrl)
Maybe I should try pattern2 ?
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 76bfff2..24d6733 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1604,6 +1604,12 @@ static int snd_soc_instantiate_card(struct snd_soc_card *card) } }
for (i = 0; i < card->num_links; i++) {if (card->dai_link[i].dai_fmt)snd_soc_runtime_set_dai_fmt(&card->rtd[i],card->dai_link[i].dai_fmt);}
This seems to be to early, the DAI's should at least have been probed. I think we should put it in soc_probe_link_dais() after the the dai_link->init section.