Alsa-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
	Aaro Koskinen <aaro.koskinen@iki.fi>,
	linux-kernel@vger.kernel.org, Merlijn Wajer <merlijn@wizzup.org>,
	Takashi Iwai <tiwai@suse.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Mark Brown <broonie@kernel.org>, Pavel Machek <pavel@ucw.cz>,
	"Arthur D ." <spinal.by@gmail.com>,
	Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
Date: Thu, 13 Feb 2020 17:34:54 -0800
Message-ID: <20200214013454.GX64767@atomide.com> (raw)
In-Reply-To: <20200214003452.xuadnylj2udqyljs@earth.universe>

* Sebastian Reichel <sre@kernel.org> [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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply index

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 17:16 Tony Lindgren
2020-02-12  8:02 ` Peter Ujfalusi
2020-02-12 14:35   ` Tony Lindgren
2020-02-14  0:34     ` Sebastian Reichel
2020-02-14  1:34       ` Tony Lindgren [this message]
2020-02-14 13:04         ` Sebastian Reichel
2020-02-14 17:09           ` Tony Lindgren
2020-02-18 14:04             ` Sebastian Reichel
2020-02-18 14:19               ` Tony Lindgren
2020-02-18 16:35                 ` Sebastian Reichel
2020-02-14 12:41     ` [alsa-devel] " Peter Ujfalusi
2020-02-14 12:49       ` Mark Brown
2020-02-14 17:05         ` Tony Lindgren
2020-02-14 20:05           ` Mark Brown
2020-02-14 17:03       ` Tony Lindgren
2020-02-17  1:38         ` Kuninori Morimoto
2020-02-17  5:25           ` Kuninori Morimoto
2020-02-17 12:09         ` Peter Ujfalusi
2020-02-17 23:10           ` Tony Lindgren
2020-02-17 23:36             ` Tony Lindgren
2020-02-18 15:26               ` Peter Ujfalusi
2020-02-18 15:34                 ` Tony Lindgren
2020-02-18 12:43             ` Peter Ujfalusi
2020-02-18 15:28               ` Tony Lindgren
2020-02-20 14:07                 ` Peter Ujfalusi
2020-02-20 20:13                   ` Tony Lindgren
2020-02-21 14:07                     ` Peter Ujfalusi
2020-02-18 21:16               ` Sebastian Reichel
2020-02-20 14:15                 ` Peter Ujfalusi
2020-02-20 20:15                   ` Tony Lindgren
2020-02-21 13:20                     ` Peter Ujfalusi
2020-02-21 18:08                       ` Tony Lindgren
2020-02-20 20:47                   ` Sebastian Reichel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200214013454.GX64767@atomide.com \
    --to=tony@atomide.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jarkko.nikula@bitmer.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=merlijn@wizzup.org \
    --cc=pavel@ucw.cz \
    --cc=peter.ujfalusi@ti.com \
    --cc=spinal.by@gmail.com \
    --cc=sre@kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Alsa-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/alsa-devel/0 alsa-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 alsa-devel alsa-devel/ https://lore.kernel.org/alsa-devel \
		alsa-devel@alsa-project.org
	public-inbox-index alsa-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.alsa-project.alsa-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git