From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8E25C433F5 for ; Mon, 25 Apr 2022 13:11:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229885AbiDYNOe (ORCPT ); Mon, 25 Apr 2022 09:14:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241937AbiDYNOW (ORCPT ); Mon, 25 Apr 2022 09:14:22 -0400 Received: from hutie.ust.cz (hutie.ust.cz [185.8.165.127]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 65A9A222A0; Mon, 25 Apr 2022 06:11:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cutebit.org; s=mail; t=1650892275; bh=/hL2s+lh63ESjiRaWWsxzMR/f4Yu9cM9nehZyfa7E0g=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=nFr8CC12dlvYY0ye7Cw0D5/WM1QFzo3/SRqKTUxMe0my0I7ZZ4f4xN63aMSAhhq2V OgPLAz4XUoeMd0sgXUnHtJxv0EqXekSKCJIIp1n11uLXZByvyi8+OxY5VoUmh4xT5z V4a8aqsvCFfG35Gz9e1wkkDP63AmJJdfBJEfXrw0= Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: [RFC PATCH 3/5] HACK: ASoC: Tolerate N-cpus-to-M-codecs links From: =?utf-8?Q?Martin_Povi=C5=A1er?= In-Reply-To: Date: Mon, 25 Apr 2022 15:11:14 +0200 Cc: =?utf-8?Q?Martin_Povi=C5=A1er?= , Liam Girdwood , Rob Herring , Krzysztof Kozlowski , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Mark Kettenis , Hector Martin , Sven Peter Content-Transfer-Encoding: quoted-printable Message-Id: <4CF6B0A7-F218-4798-BB21-18D563309D5C@cutebit.org> References: <20220331000449.41062-1-povik+lin@cutebit.org> <20220331000449.41062-4-povik+lin@cutebit.org> <904EB8A1-5561-4555-8030-B85703E24F2E@cutebit.org> <9F8BCBA8-5EE3-4F87-9518-91CB7AB4E077@cutebit.org> To: Mark Brown Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org > On 25. 4. 2022, at 14:55, Mark Brown wrote: >=20 > On Mon, Apr 25, 2022 at 02:34:33PM +0200, Martin Povi=C5=A1er wrote: >>> On 25. 4. 2022, at 14:25, Mark Brown wrote: >=20 >>> 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. >=20 >> Sure, but what I am addressing here is a single DAI link with = multiple >> CPU DAIs, invoked in DT like this: >=20 >> dai-link@0 { >> link-name =3D "Speakers"; >> mclk-fs =3D <256>; >>=20 >> cpu { >> sound-dai =3D <&mca 0>, <&mca 1>; >> }; >> codec { >> sound-dai =3D <&speaker_left_woof1>, >> <&speaker_right_woof1>, >> <&speaker_left_tweet>, >> <&speaker_right_tweet>, >> <&speaker_left_woof2>, >> <&speaker_right_woof2>; >> }; >> }; >=20 > 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 =E2=80=98macaudio=E2=80=99 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. >=20 >>> That's not the issue here? >=20 >> 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. >=20 > 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.