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