Re: [PATCH v3 2/3] ASoC: soc-pcm: Indicate warning if CPU / Codec availability mismatch

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

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