Hi Pierre-Louis
Thank you for your feedback and report
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.
I think my patch have escape mechanism, but it was for BE Codec. If my understand was correct, above is FE Codec ?
One question is that is it just a mistake (no one noticed) ? or is there some reasons it can't support capture (but use it ?). If it was just a mistake, is it possible to update driver during the grace time ? Or do you think we need "escape mechanism" permanently ?
I agree with your analysis. We don't have a clear memory/understanding of which "no_chan_DAI" platforms (B) was supposed to handle, and why no one reported them as broken by (C).
(snip)
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.
Thanks. It seems the code was just complicated, and we have been missing important check. Let's break out my patch-set into small pieces, and go more slowly.
I think it will be like below. Can you agree about this ?
Step1 dpcm_xxx flag will be "option flag" instead of "mandatory flag" for a while to keep compatibility and avoide confusion. But it will be removed in Step3. To indicate such things, it will have dev_warn() if dpcm_xxx flag was used. like below
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { has_playback = /* at least one of CPU DAI supports playback */ has_capture = ...
if (!playback && rtd->dai_link->dpcm_playback) { dev_warn(dev, "Playback is requested, but CPU doesn't support it\n") has_playback = 1; } ...
Step2 (In case of "escape mechanism" is not needed)
Current DPCM is checking CPU side only. Indicate warning until Step4 if Codec is not match . warning only, not error for a while. if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) { ...
if (has_playback && /* no Codec DAI supports playback */) dev_warn(dev, "Playback is requested, but Codec doesn't support it\n") ...
Step3
Step1 deadline remove dpcm_xxx flag
Step4 Step2 deadline CPU / Codec mismatch will be error. It will be "at least one of CPU/Codec pair supports playback/capture"
Step5
There is no big diff between DPCM / non-DPCM check. Merge these, and clean-up code (soc_get_playback_capture())
Thank you for your help !!
Best regards --- Renesas Electronics Ph.D. Kuninori Morimoto