On 25. 4. 2022, at 14:55, Mark Brown broonie@kernel.org wrote:
On Mon, Apr 25, 2022 at 02:34:33PM +0200, Martin Povišer wrote:
On 25. 4. 2022, at 14:25, Mark Brown broonie@kernel.org wrote:
If you register two separate DAIs (well, links) with the API without doing anything else the API will just expose them to userspace as two separate things with no indication that they're related.
Sure, but what I am addressing here is a single DAI link with multiple CPU DAIs, invoked in DT like this:
dai-link@0 { link-name = "Speakers"; mclk-fs = <256>;
cpu { sound-dai = <&mca 0>, <&mca 1>; }; codec { sound-dai = <&speaker_left_woof1>, <&speaker_right_woof1>, <&speaker_left_tweet>, <&speaker_right_tweet>, <&speaker_left_woof2>, <&speaker_right_woof2>; };};
You could parse this into two separate links for the benefit of the framewokr if you're using a custom machine driver (which I suspect you probably have to).
Yeah, this is parsed by the ‘macaudio’ machine driver from the series.
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.
That's not the issue here?
Well to me it looks like it is. Because if I invoke the DAI link like I quoted above, and the platform driver supports it, the playback/capture stream validity check is the only place it breaks down. Notwithstanding this may be the wrong API as you wrote.
I am surprised that doesn't otherwise explode TBH - at the very least I'd expect it to show two PCMs to userspace which if I'm understanding your description correctly isn't really what's going on.
I fill in a single snd_soc_dai_link, it exposes a single PCM and works like a charm. That is as long as I patch the playback/capture check in question.
I read that to be the clear intention of ASoC code: a DAI link becomes one snd_soc_pcm_runtime.