On 2020-03-06 20:49, Pierre-Louis Bossart wrote:
Guys, we've simply taken long-standing working example such as skl_rt286 or bxt_rt298 and applied the missing diff between skl_hda_dsp's and said machine boards DAPM routes. skl-pcm.c exposes BE: DMIC01 Rx which Intel's SST topologies link against via dmic01_hifi. That has always been the case. No bad intentions, the exact opposite is true: taken old path approach to make sure nothing is broken. Turns out SOF does things differently. Thanks for spotting/ testing this out on your end.
It's actually not SOF, but recent changes in the asoc core that will stop the probe if a route cannot be added, instead of just spewing a warning.
I think it's a good change to force topologies to be complete, but in cases where a previously released topology cannot be adjusted we need a backwards compatible solution. that's my plan for the rest of the afternoon.
Agree, missing topology routes should not be permissive. Although my point was about the fact that those 2 routes actually exist in every SST machine driver (in essence linking DMIC01 Rx with platform via internal dmic01_hifi widget).
Not a problem to adjust topology on our end, though. In fact, I've already done that on your requested, tested it out and it works just fine. In consequence:
- this patch will be dropped from the series
- topology patch provided for alsa-ucm-conf will be updated
accordingly (dmic01_hifi widget will cease to exist)
Sounds good, thanks Cezary.
Awaiting comments for the rest of the patches if any! Especially how low - kernel version wise - should the fixes be backported.
Thanks in advance for your input and time.
Czarek