But because we have been used dpcm_xxx for 10 years since (B), I understand to feel anxious to suddenly remove dpcm_xxx.
Indeed we err on the side of paranoia with such changes!
I think it should be removed anyway, but want to have grace time ? If so, the idea is that we can use it as "option flag" instead of "mandatory flag" for a while, like below
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { playback = (cpu_dai->driver->playback.channels_min > 0) || rtd->dai_link->dpcm_playback; capture = (cpu_dai->driver->capture.channels_min > 0) || rtd->dai_link->dpcm_capture;
- maybe we want to indicate message like "place re-check the flag and remove it" via dev_info() if dpcm_xxx flag was used ?
I think +2 kernel version or so is enough for grace time ? After that, we can remove dpcm_xxx flag.
I am good with that plan, but I'll need to investigate first why we had a failure with one of the Chromebooks on this v3 patchset. That may give us some insights on "special" uses of those flags.
I found the reason why this patchset failed on Intel CI: a dailink direction is deemed supported only if ALL cpu- and codec-dais support it.
That is a stricter criterion than in existing code. This was a good intention based on symmetry, but in practice there are exceptions to the rule...
On some Chromebooks, we tag a dailink as supporting capture for echo reference, but that echo reference is generated by the Intel firmware. The amplifiers only support playback.
see https://github.com/thesofproject/linux/pull/4937 for details, I added a clear log:
[ 807.304740] kernel: SSP1-Codec: CPU dai SSP1 Pin supports capture but codec DAI rt1011-aif does not
So I think for now we probably want to avoid this stricter criterion and only check the supported direction with the cpu-dais. Or we add an escape mechanism to let the core know that the capture support was intentional.
Also we relax the checks to go back to (E) 4f8721542f7b75954bfad98c51aa59d683d35b50 ("ASoC: core: use less strict tests for dailink capabilities")
" This patch modifies the snd_soc_dai_link_set_capabilities() helper so that the dpcm_playback (resp. dpcm_capture) dailink capabilities are set if at least one [cpu-]dai supports playback (resp. capture). "
We tried checking all cpu-dais before and found issues, so "at least one cpu dai" seems the strictest test to apply without breaking legacy.