lkml.org 
[lkml]   [2022]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 3/5] HACK: ASoC: Tolerate N-cpus-to-M-codecs links
From
Date

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

\
 
 \ /
  Last update: 2022-04-22 16:06    [W:0.087 / U:0.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site