Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1183438ybv; Thu, 13 Feb 2020 17:35:37 -0800 (PST) X-Google-Smtp-Source: APXvYqzUP2zgudqV3ygiX9IkYvQoCqPLGAa7GzTBjO6mdzllULPbePoOVi1DlkTCHcVgfE+AVz+s X-Received: by 2002:a9d:5d09:: with SMTP id b9mr328253oti.207.1581644137448; Thu, 13 Feb 2020 17:35:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581644137; cv=none; d=google.com; s=arc-20160816; b=rS/FWaBkU6R6ezrz5Eh57n2djMa7SLND63rqPYea8VSBbAOnmAEaaCgu7JWrpbltQ8 8zfRwVB2eiK/kjdg+yU2+U2+JTOsK2pPBfiWCx9nsuAilGIBNtgjY92hf+yIXrMhExsY 7tFS0NSHli5jqic5HcjjPce/xufEA92zQvodoua99b+7jqlxZxvKz1+BIgiq67Kg9u2Y vs+od+eZMfsMEobSLjFxLm4l5q+vujFgQlVgpp72KG5StLd+RSzld+uvboGnDooAQNpZ m31FmhOB9tF06+6r4E5Akxo1jFwf2o4N8tnlr7kabmWbNLn9juh7ChUt54X1rK/v6Nav 2Ibg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=uK35DlktmoYtRqwQe6QdO4p1tDQYnNWSnm5S3vz3R0o=; b=b8RhcuvBRdSRhavAbpUFKoIvEv7I4SZpXoq04jOvJb9U4Wi9jgx0PJrd3Xs1H+a+uh AqzyUg3x8oIqy7dt9y4exWU1wKmARWTI2PM+yqr84DGrHvEnyHfEJmy8de1jZyzEOyfD K2cFs6A6aAoRAQOyJiVLQyz8jHAdNQWnbabiScFvHTvXnwfNA4O1fBbYGO/iOQk+sVS2 mJT7Y84/kQRSR1e1yyUimqckvfly7BFWabL9WRxe27beaP3WCeQpev4U/gJHUc3+JroB mywuB/ZVFOgEGacUnO3XWQ6USAKKkvsTRVeTLI36DERzb23v1YDQ8Kt232vwiXTl8Hm7 JxZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f14si1855098oto.46.2020.02.13.17.35.24; Thu, 13 Feb 2020 17:35:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728195AbgBNBfA (ORCPT + 99 others); Thu, 13 Feb 2020 20:35:00 -0500 Received: from muru.com ([72.249.23.125]:55160 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728052AbgBNBfA (ORCPT ); Thu, 13 Feb 2020 20:35:00 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 6A538804F; Fri, 14 Feb 2020 01:35:41 +0000 (UTC) Date: Thu, 13 Feb 2020 17:34:54 -0800 From: Tony Lindgren To: Sebastian Reichel Cc: Peter Ujfalusi , Mark Brown , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org, Aaro Koskinen , "Arthur D ." , Jarkko Nikula , Merlijn Wajer , Pavel Machek Subject: Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card Message-ID: <20200214013454.GX64767@atomide.com> References: <20200211171645.41990-1-tony@atomide.com> <20200212143543.GI64767@atomide.com> <20200214003452.xuadnylj2udqyljs@earth.universe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200214003452.xuadnylj2udqyljs@earth.universe> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Sebastian Reichel [200214 00:35]: > On Wed, Feb 12, 2020 at 06:35:43AM -0800, Tony Lindgren wrote: > > Yes this should follow the audio-graph-card.txt example. We end up with > > mcbsp3 dts node as below on droid4: > > > > &mcbsp3 { > > #sound-dai-cells = <0>; > > pinctrl-names = "default"; > > pinctrl-0 = <&mcbsp3_pins>; > > status = "okay"; > > > > ports { > > mcbsp3_port: port@0 { > > #address-cells = <1>; > > #size-cells = <0>; > > > > cpu_dai3: endpoint@0 { > > cpu_dai3_cpcap > > > reg = <0>; > > dai-format = "dsp_a"; > > frame-master = <&cpcap_audio_codec1>; > > bitclock-master = <&cpcap_audio_codec1>; > > remote-endpoint = <&cpcap_audio_codec1>; > > }; > > > > cpu_dai_mdm: endpoint@1 { > > cpu_dai3_mdm OK > > reg = <1>; > > dai-format = "dsp_a"; > > frame-master = <&cpcap_audio_codec1>; > > bitclock-master = <&cpcap_audio_codec1>; > > remote-endpoint = <&mot_mdm6600_audio_codec0>; > > }; > > }; > > }; > > }; > > > > That is pretty much the same as the 'Multi DAI with DPCM' example, with > > dne dai, and multiple endpoints. I think we still have just one port > > for one i2s transport on the mcbsp :) > > > > Does the above look as what you would expect based on the binding? > > I haven't had a look at this for quite some time. I suppose the > cpcap voice DAI and the modem will also have two endpoints? So > once the BT support is added it will looks like this [simplified]? Well it will be even simpler, no need for extra endpoints at the codecs, see below. > &mcbsp3 { > ports { > port@0 { > cpu_dai3_cpcap: endpoint@0 {}; > cpu_dai3_modem: endpoint@1 {}; > cpu_dai3_bt: endpoint@2 {}; > }; > }; > }; But yes, bluetooth would be just added as above under mcbsp3. > &cpcap { > ports { > voice: port@1 { > cpcap_voice_cpu: endpoint@0 {}; > cpcap_voice_modem: endpoint@1 {}; > cpcap_voice_bt: endpoint@2 {}; > }; > }; > }; But above there's no need to add anything under cpcap, it still only has the same two endpoints as it already has. So it's just as specified in the graph binding, just the #address-cells, #size-cells and reg added: cpcap_audio: audio-codec { #sound-dai-cells = <1>; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; cpcap_audio_codec0: endpoint { }; }; port@1 { reg = <1>; cpcap_audio_codec1: endpoint { }; }; }; Then the modem codec looks like this: mot_mdm6600_audio: audio-codec { #address-cells = <1>; #size-cells = <0>; #sound-dai-cells = <1>; port@0 { mot_mdm6600_audio_codec0: endpoint { remote-endpoint = <&cpu_dai_mdm>; }; }; }; > &bluetooth { > ports { > port@0 { > bt_dai_cpu: endpoint@0 {}; > bt_dai_modem: endpoint@1 {}; > bt_dai_cpcap: endpoint@2 {}; > }; > }; > }; And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio above. My guess is that only cpcap registers and clock rate needs to be changed for bluetooth audio BTW, so if somebody havs a bluetooth headset just do the following in Android: # cpcaprw --all > /tmp/before configure bluetooth headset for audio in android and start playing some music or make a phone call ... # cpcaprw --all > /tmp/after stop playing music or phone call ... diff -u /tmp/before /tmp/after The registers will be different for a bluetooth phone call and playing music. > > > > I've tested this with droid4 where cpcap pmic and modem voice are both > > > > both wired to mcbsp3. I've also tested this on droid4 both with and > > > > without the pending modem audio codec driver that is waiting for n_gsm > > > > serdev dependencies to clear. > > > > > > What this patch you effectively just creating dummy-dais on top of the > > > real McBSP DAI. > > > > Yes I think this is needed for snd-soc-audio-graph-card, and this allows > > configuring whatever is needed for the i2s slot. But maybe you have some > > better way of doing it in mind? > > > > > You also rename the DAIs, which might break ams-delta. > > > > Oops, that's not good. So should we just keep the old naming if there's > > only one endpoint? > > > > > We still have legacy support in > > > omap-twl4030.c > > > omap3pandora.c > > > osk5912.c > > > rx51.c > > also n810.c OK > > > which will break with the renamed DAI. On the other hand I think the > > > legacy support can be dropped from them. > > > > I'm not sure what all that would take. > > rx51 and omap-twl4030 override the hardcoded paths with DT > information when DT is available (= always), so hardcoded paths > do not matter at all and could simply be removed (the patch > should also make DT mandatory). > > For omap3pandora, n810 and osk5912 the hardcoded information seems > to be used and there does not seem to be any soundcard DT node for > them. I suppose it's a bit of work for those devices. n810 > looks simple enough to just use simple-card. OK I'll just keep the old naming if there's only one child node. Regards, Tony