I mentioned in my previous feedback that this isn't quite right. There are cases where the CPU dai reports capabilities that the codec DAI does not support - e.g. when the AEC reference is generated in firmware on the host DSP.
Hmm... I thought all issue was solved...
For those systems, trying to match CPU and codec dais is not going to work. Either we skip this verification or we have an escape mechanism to avoid triggering errors.
Sorry, but I'm not 100% understand about your situation. Why Codec can't have channels_min ? If the Codec can flexibly adjust to paired CPU, Codec can have full channels support, like dummy DAI ? This means verification is based on CPU only. Is it not enough ? and/or Can you show me the driver ?
static struct snd_soc_dai_driver dummy_dai = { ... .playback = { => .channels_min = 1, => .channels_max = 384, ... }, .capture = { ... => .channels_min = 1, => .channels_max = 384, ... }, ... };
We cannot change the Maxim amplifier driver, it's used in a variety of usages and platforms, and there's no reason to create a fake capture dai just to reflect the use of a capture stream on the CPU side on some Chromebooks.
The dailinks used for amplifiers in sound/soc/intel/boards/sof_boards_helpers.c set dpcm_capture always
link->dpcm_capture = 1; /* feedback stream or firmware-generated echo reference */
which means that this test will fail:
if ((dai_link->dpcm_capture || dai_link->capture_only) && !has_capture_both)
I don't disagree that the unconditional use of dpcm_capture isn't very elegant, but it is what it is. This platform has been around since 2019 and still has about 6 or 7 years of support, so we can't break it with stricter criteria.