> On 4. 4. 2022, at 14:28, Mark Brown <broonie@xxxxxxxxxx> 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.
