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 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 422B6C11D27 for ; Thu, 20 Feb 2020 20:48:35 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C3E2D20801 for ; Thu, 20 Feb 2020 20:48:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="k0H0ITfy"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="d/MuCgRG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C3E2D20801 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 257411686; Thu, 20 Feb 2020 21:47:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 257411686 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1582231713; bh=zhAIqLnnnv+wodCzFnBPaFPLL1axodY6rIUf0WW6IXA=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=k0H0ITfy+I6b4vHivR5JE/oN4fCLMLdKs3biY4uqrsQUyRAfRNvPQZAn+gFs0I2Ud WjeJgPNV5O/Qcmv33OpUEsyTP4BNGaU0xLSTnQ7Y731ScPpCdEj/EYhWL2WbROmq6l Z2NAgkYI5dvHK4eCXIJR4W1HMK0RA5GIKAyzDDgc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 98AE0F80145; Thu, 20 Feb 2020 21:47:42 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5D7B6F80148; Thu, 20 Feb 2020 21:47:41 +0100 (CET) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 92663F8011D for ; Thu, 20 Feb 2020 21:47:38 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 92663F8011D Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="d/MuCgRG" Received: from earth.universe (unknown [185.62.205.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8EF53208CD; Thu, 20 Feb 2020 20:47:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582231655; bh=zhAIqLnnnv+wodCzFnBPaFPLL1axodY6rIUf0WW6IXA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=d/MuCgRGhzj4SWM35SD0udulwCF++XSwdk6qoVb/vDe0O/IdUOopK+nJHPL2jApYF FQYTrlZTy+tMMPncuKH3JAnyr06NbncLW1PbKANYkgvP8SPRCF1cYhFm0vWzGaDUSS +adLvgsIyCqEdWHFTz5CCMEt613I5qcRUfgczAD0= Received: by earth.universe (Postfix, from userid 1000) id 1142E3C0C83; Thu, 20 Feb 2020 21:47:33 +0100 (CET) Date: Thu, 20 Feb 2020 21:47:33 +0100 From: Sebastian Reichel To: Peter Ujfalusi Subject: Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card Message-ID: <20200220204733.ktzhmmaytnglr5nh@earth.universe> References: <20200211171645.41990-1-tony@atomide.com> <20200212143543.GI64767@atomide.com> <346dfd2b-23f8-87e0-6f45-27a5099b1066@ti.com> <20200214170322.GZ64767@atomide.com> <20200217231001.GC35972@atomide.com> <5402eba8-4f84-0973-e11b-6ab2667ada85@ti.com> <20200218211631.fxojsxzvttoidfed@earth.universe> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dedczlb2yot6jtdy" Content-Disposition: inline In-Reply-To: Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org, Kuninori Morimoto , Aaro Koskinen , Tony Lindgren , linux-kernel@vger.kernel.org, Merlijn Wajer , Takashi Iwai , Liam Girdwood , Mark Brown , Pavel Machek , "Arthur D ." , Jarkko Nikula X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" --dedczlb2yot6jtdy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Feb 20, 2020 at 04:15:22PM +0200, Peter Ujfalusi wrote: > > I suppose in the end its a question if generic card can provide TDM > > support. >=20 > Sure it can, but can it handle the switching between the paths based on > use cases? > There should be machine level DAPM widgets to kick codec2codec (MDM6600 > - CPAC_voice for example) and also to make sure that when you switch > between them the system is not going to get misconfigured. > Switching between CPAC and BT route during call? > Not allowing VoIP while on call, etc. I think the main issue is, that based on the route configuration (which could be a simple DAPM widget generated by the simple-graph-card), we may need to configure different bitrates. Tony's hack adding this knowledge to the cpcap driver is very ugly. > >> In case of B/C you should not have a running stream imho. > >=20 > > I would expect, that MDM6600 codec marks itself as running/stopped > > based on call state. That should enable DAPM widgets automatically > > when CPCAP_voice is routed to MDM6600? > >=20 > >> In all cases CPCAP_voice should be able to run the clocks on i2s, > >> even if it is not used by the audio setup. > >> Not sure if you can just turn Wl1285 as master, but it is possible > >> that it is master, but silent when it is not used? > >=20 > > I provided CPCAP registers for BT call, which should be enough to > > figure this out (I did not yet analyze the results myself). >=20 > I got the datasheet from NXP (thanks for the pointer!), I try to look at > it in a coming days. FWIW the datasheet is not for the same chip, but for a similar one. The audio part seems to be very similar though. -- Sebastian --dedczlb2yot6jtdy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAl5O8GEACgkQ2O7X88g7 +pqQ/hAAgEqBO6UXtQnbUsOTqAxQ6FWYfr2uOwPllZ/qaDcYwXg4/JKMDlkdj/TN NVLSo98L3HRUIyVzofJJ8/mNuz26OnUDF+Jmp/NDVyWm494i284b4UcejTuq2QZF PIUBEuEZAbXjZssKqNiWLK0sIbhSfGGjFwKMHJL7u5hnQ4LTBtjIbiQ7hcIfZIR0 wxpoMupM9HqVuw3Ulic8Vq8bIWWbVy2S8ockuZn5H9R6fACBGJA+gJCcv+jb0xDl 18Nf/b/aYsufjaNuX+cxEI2h8xvzzzr/hOAhXoBTju6UPFr4bHUmDPhV3ycxRMib eRgZ96TX6Gur53dPVz2KxG1Xx6LDsLfqYAvojww6PL5O37xx531jk+z/5w4yUvB1 zNOq8dEyJsPFfG3JH3racUr/GEkdllORvAn5T5Dbbt28kEFs7YuDujwe5yIXi/YR Ve557gjSI6/xWSTA4zlJjzffOYWBg67+JDRiw/V1C1sV+1Eqx+xGsGhq9QqNqyld lkAh3Z5FNPvQbgFofHn+7l7VPu2FH4SfVDow2DCa7gEee90Wwr8SxxaQ/+z6Tghw tOTTER2jXWCdZ74WxrJITLKVT4SRBXwNvcC9/jNMiHmb8q6T9Zr2lmJQ13GRyCoT 2YBZjeEgOkLi8aKbqHMT3lgfK1r9j43SRZCGy2i/zCc0PiIN+L4= =d1zp -----END PGP SIGNATURE----- --dedczlb2yot6jtdy--