@@ -167,9 +167,6 @@ SND_SOC_DAILINK_DEF(codec,
#if IS_ENABLED(CONFIG_SND_SOC_SOF_BROADWELL)
SND_SOC_DAILINK_DEF(ssp0_port,
DAILINK_COMP_ARRAY(COMP_CPU("ssp0-port")));
-#else
-SND_SOC_DAILINK_DEF(ssp0_port,
- DAILINK_COMP_ARRAY(COMP_DUMMY()));
#endif
/* broadwell digital audio interface glue - connects codec <--> CPU */
@@ -225,7 +222,11 @@ static struct snd_soc_dai_link broadwell_rt286_dais[] = {
.ops = &broadwell_rt286_ops,
.dpcm_playback = 1,
.dpcm_capture = 1,
+#if !IS_ENABLED(CONFIG_SND_SOC_SOF_BROADWELL)
+ SND_SOC_DAILINK_REG(dummy, codec, dummy),
+#else
SND_SOC_DAILINK_REG(ssp0_port, codec, platform),
+#endif
},
};
Recent series of patches targeting broadwell boards, while enabling SOF, changed behavior for non-SOF solutions. In essence replacing platform 'dummy' with actual 'platform' causes redundant stream initialization to occur during audio start. hw_params for haswell-pcm destroys initial stream right after its creation - only to recreate it again from proceed from there. While harmless so far, this flow isn't correct and should be corrected. The actual need for dummy components for SSP0 link is questionable but that issue is subject for another series. Link to first message in conversation: https://lkml.org/lkml/2020/3/18/54 Reported-by: Dominik Brodowski <linux@dominikbrodowski.net> Fixes: 64df6afa0dab ("ASoC: Intel: broadwell: change cpu_dai and platform components for SOF") Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> --- sound/soc/intel/boards/broadwell.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)