[RFC PATCH 3/5] HACK: ASoC: Tolerate N-cpus-to-M-codecs links

[Martin Povišer]

> On 4. 4. 2022, at 14:28, Mark Brown <broonie at kernel.org> wrote:
> 
> On Thu, Mar 31, 2022 at 02:04:47AM +0200, Martin Povišer wrote:
> 
>> +#if 0
>> 				dev_err(rtd->card->dev,
>> 					"N cpus to M codecs link is not supported yet\n");
>> 				return -EINVAL;
>> +#endif
>> +				cpu_dai = asoc_rtd_to_cpu(rtd, 0);
> 
> We need to figure out an interface for describing which CODEC/CPU
> combinations are connected to each other.  I'm not seeing a great way to
> do that right now, probably some side data table is going to be needed,
> or perhaps the CPU DAI drivers can be persuaded to only have one DAI
> actually register and claim to support more channels?  I'm not sure how
> a configuraiton like this is going to work at userspace level if the
> multiple CPU DAIs end up being visible...

To understand the issue better: How could the multiple CPU DAIs be
visible from userspace?

What about this interim solution: In case of N-to-M links we put in
the most restrictive condition for checking capture/playback stream
validity: we check all of the CPU DAIs. Whatever ends up being the
proper solution later can only be less restrictive than this.

As a reminder what happens on the Macs: the platform driver drives
all the CPU-side I2S ports that belong to the link with the same data,
so the particular CPU/CODEC wiring doesn’t matter.