Re: [PATCH v3 01/23] ASoC: soc-pcm: cleanup soc_get_playback_capture()

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

>> 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.