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
