On Mon, Apr 25, 2022 at 02:34:33PM +0200, Martin PoviĊĦer wrote: > > On 25. 4. 2022, at 14:25, Mark Brown 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). > >> 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.