[PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 4865 bytes --]

From: Tony Lindgren <tony@atomide.com>

We can have multiple connections on a single McBSP instance configured
with audio graph card when using TDM (Time Division Multiplexing). Let's
allow that by configuring dais dynamically.

See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
Documentation/devicetree/bindings/graph.txt for more details for
multiple endpoints.

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.

Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Arthur D. <spinal.by@gmail.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>

---
 sound/soc/ti/omap-mcbsp-priv.h |  2 ++
 sound/soc/ti/omap-mcbsp.c      | 76 +++++++++++++++++++++++++++++-------------
 2 files changed, 55 insertions(+), 23 deletions(-)

diff --git a/sound/soc/ti/omap-mcbsp-priv.h b/sound/soc/ti/omap-mcbsp-priv.h
index 7865cda4bf0a..9464f5d35822 100644
--- a/sound/soc/ti/omap-mcbsp-priv.h
+++ b/sound/soc/ti/omap-mcbsp-priv.h
@@ -262,6 +262,8 @@ struct omap_mcbsp {
 	struct omap_mcbsp_platform_data *pdata;
 	struct omap_mcbsp_st_data *st_data;
 	struct omap_mcbsp_reg_cfg cfg_regs;
+	struct snd_soc_dai_driver *dais;
+	int dai_count;
 	struct snd_dmaengine_dai_dma_data dma_data[2];
 	unsigned int dma_req[2];
 	int dma_op_mode;
diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c
index 6025b30bbe77..189a6461b671 100644
--- a/sound/soc/ti/omap-mcbsp.c
+++ b/sound/soc/ti/omap-mcbsp.c
@@ -14,6 +14,7 @@
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
 #include <linux/of_device.h>
+#include <linux/of_graph.h>
 #include <sound/core.h>
 #include <sound/pcm.h>
 #include <sound/pcm_params.h>
@@ -1299,23 +1300,53 @@ static int omap_mcbsp_remove(struct snd_soc_dai *dai)
 	return 0;
 }
 
-static struct snd_soc_dai_driver omap_mcbsp_dai = {
-	.probe = omap_mcbsp_probe,
-	.remove = omap_mcbsp_remove,
-	.playback = {
-		.channels_min = 1,
-		.channels_max = 16,
-		.rates = OMAP_MCBSP_RATES,
-		.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
-	},
-	.capture = {
-		.channels_min = 1,
-		.channels_max = 16,
-		.rates = OMAP_MCBSP_RATES,
-		.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
-	},
-	.ops = &mcbsp_dai_ops,
-};
+static int omap_mcbsp_init_dais(struct omap_mcbsp *mcbsp)
+{
+	struct device_node *np = mcbsp->dev->of_node;
+	int i;
+
+	if (np)
+		mcbsp->dai_count = of_graph_get_endpoint_count(np);
+
+	if (!mcbsp->dai_count)
+		mcbsp->dai_count = 1;
+
+	mcbsp->dais = devm_kcalloc(mcbsp->dev, mcbsp->dai_count,
+				   sizeof(*mcbsp->dais), GFP_KERNEL);
+	if (!mcbsp->dais)
+		return -ENOMEM;
+
+	for (i = 0; i < mcbsp->dai_count; i++) {
+		struct snd_soc_dai_driver *dai = &mcbsp->dais[i];
+
+		dai->name = devm_kasprintf(mcbsp->dev, GFP_KERNEL, "%s-dai%i",
+					   dev_name(mcbsp->dev), i);
+
+		if (i == 0) {
+			dai->probe = omap_mcbsp_probe;
+			dai->remove = omap_mcbsp_remove;
+			dai->ops = &mcbsp_dai_ops;
+		}
+		dai->playback.channels_min = 1;
+		dai->playback.channels_max = 16;
+		dai->playback.rates = OMAP_MCBSP_RATES;
+		if (mcbsp->pdata->reg_size == 2)
+			dai->playback.formats = SNDRV_PCM_FMTBIT_S16_LE;
+		else
+			dai->playback.formats = SNDRV_PCM_FMTBIT_S16_LE |
+						SNDRV_PCM_FMTBIT_S32_LE;
+		dai->capture.channels_min = 1;
+		dai->capture.channels_max = 16;
+		dai->capture.rates = OMAP_MCBSP_RATES;
+		if (mcbsp->pdata->reg_size == 2)
+			dai->capture.formats = SNDRV_PCM_FMTBIT_S16_LE;
+		else
+			dai->capture.formats = SNDRV_PCM_FMTBIT_S16_LE |
+					       SNDRV_PCM_FMTBIT_S32_LE;
+	}
+
+	return 0;
+}
 
 static const struct snd_soc_component_driver omap_mcbsp_component = {
 	.name		= "omap-mcbsp",
@@ -1404,18 +1435,17 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
 	mcbsp->dev = &pdev->dev;
 	platform_set_drvdata(pdev, mcbsp);
 
-	ret = omap_mcbsp_init(pdev);
+	ret = omap_mcbsp_init_dais(mcbsp);
 	if (ret)
 		return ret;
 
-	if (mcbsp->pdata->reg_size == 2) {
-		omap_mcbsp_dai.playback.formats = SNDRV_PCM_FMTBIT_S16_LE;
-		omap_mcbsp_dai.capture.formats = SNDRV_PCM_FMTBIT_S16_LE;
-	}
+	ret = omap_mcbsp_init(pdev);
+	if (ret)
+		return ret;
 
 	ret = devm_snd_soc_register_component(&pdev->dev,
 					      &omap_mcbsp_component,
-					      &omap_mcbsp_dai, 1);
+					      mcbsp->dais, mcbsp->dai_count);
 	if (ret)
 		return ret;
 
-- 
2.11.0

-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Péter Ujfalusi]

Hi Pavel,

On 1/24/21 11:27 AM, Pavel Machek wrote:
> From: Tony Lindgren <tony@atomide.com>
> 
> We can have multiple connections on a single McBSP instance configured
> with audio graph card when using TDM (Time Division Multiplexing). Let's
> allow that by configuring dais dynamically.

Still we have _one_ DAI per McBSP. TDM slots are not DAIs.

> See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
> Documentation/devicetree/bindings/graph.txt for more details for
> multiple endpoints.

Documentation/devicetree/bindings/sound/audio-graph-card.yaml
Documentation/devicetree/bindings/sound/audio-graph.yaml

However the schemas does not provide too much insight (the txts were a 
bit more verbose).

> 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.
 >
> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
> Cc: Arthur D. <spinal.by@gmail.com>
> Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
> Cc: Merlijn Wajer <merlijn@wizzup.org>
> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Cc: Sebastian Reichel <sre@kernel.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
> 
> ---
>   sound/soc/ti/omap-mcbsp-priv.h |  2 ++
>   sound/soc/ti/omap-mcbsp.c      | 76 +++++++++++++++++++++++++++++-------------
>   2 files changed, 55 insertions(+), 23 deletions(-)
> 
> diff --git a/sound/soc/ti/omap-mcbsp-priv.h b/sound/soc/ti/omap-mcbsp-priv.h
> index 7865cda4bf0a..9464f5d35822 100644
> --- a/sound/soc/ti/omap-mcbsp-priv.h
> +++ b/sound/soc/ti/omap-mcbsp-priv.h
> @@ -262,6 +262,8 @@ struct omap_mcbsp {
>   	struct omap_mcbsp_platform_data *pdata;
>   	struct omap_mcbsp_st_data *st_data;
>   	struct omap_mcbsp_reg_cfg cfg_regs;
> +	struct snd_soc_dai_driver *dais;
> +	int dai_count;
>   	struct snd_dmaengine_dai_dma_data dma_data[2];
>   	unsigned int dma_req[2];
>   	int dma_op_mode;
> diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c
> index 6025b30bbe77..189a6461b671 100644
> --- a/sound/soc/ti/omap-mcbsp.c
> +++ b/sound/soc/ti/omap-mcbsp.c
> @@ -14,6 +14,7 @@
>   #include <linux/pm_runtime.h>
>   #include <linux/of.h>
>   #include <linux/of_device.h>
> +#include <linux/of_graph.h>
>   #include <sound/core.h>
>   #include <sound/pcm.h>
>   #include <sound/pcm_params.h>
> @@ -1299,23 +1300,53 @@ static int omap_mcbsp_remove(struct snd_soc_dai *dai)
>   	return 0;
>   }
>   
> -static struct snd_soc_dai_driver omap_mcbsp_dai = {
> -	.probe = omap_mcbsp_probe,
> -	.remove = omap_mcbsp_remove,
> -	.playback = {
> -		.channels_min = 1,
> -		.channels_max = 16,
> -		.rates = OMAP_MCBSP_RATES,
> -		.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
> -	},
> -	.capture = {
> -		.channels_min = 1,
> -		.channels_max = 16,
> -		.rates = OMAP_MCBSP_RATES,
> -		.formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE,
> -	},
> -	.ops = &mcbsp_dai_ops,
> -};
> +static int omap_mcbsp_init_dais(struct omap_mcbsp *mcbsp)
> +{
> +	struct device_node *np = mcbsp->dev->of_node;
> +	int i;
> +
> +	if (np)
> +		mcbsp->dai_count = of_graph_get_endpoint_count(np);
> +
> +	if (!mcbsp->dai_count)
> +		mcbsp->dai_count = 1;
> +
> +	mcbsp->dais = devm_kcalloc(mcbsp->dev, mcbsp->dai_count,
> +				   sizeof(*mcbsp->dais), GFP_KERNEL);
> +	if (!mcbsp->dais)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < mcbsp->dai_count; i++) {
> +		struct snd_soc_dai_driver *dai = &mcbsp->dais[i];
> +
> +		dai->name = devm_kasprintf(mcbsp->dev, GFP_KERNEL, "%s-dai%i",
> +					   dev_name(mcbsp->dev), i);
> +
> +		if (i == 0) {
> +			dai->probe = omap_mcbsp_probe;
> +			dai->remove = omap_mcbsp_remove;
> +			dai->ops = &mcbsp_dai_ops;
> +		}

You are effectively creating extra dummy-dais (no ops), but naming them 
as McBSP.
The dummy-dais will only work if the real dai is in use and the dai link 
which contains the real dai must be configured (TDM slots, format, 
channels) to accomodate the link which contains the dummy-dai.

The idea did not aged well for me ;)
It still looks and sounds like a hack to model the TDM slots on a single 
DAI as multiple DAIs just to satisfy a generic binding which is not 
aimed to satisfy the droid4 setup (which is far from anything simple).

> +		dai->playback.channels_min = 1;
> +		dai->playback.channels_max = 16;
> +		dai->playback.rates = OMAP_MCBSP_RATES;
> +		if (mcbsp->pdata->reg_size == 2)
> +			dai->playback.formats = SNDRV_PCM_FMTBIT_S16_LE;
> +		else
> +			dai->playback.formats = SNDRV_PCM_FMTBIT_S16_LE |
> +						SNDRV_PCM_FMTBIT_S32_LE;
> +		dai->capture.channels_min = 1;
> +		dai->capture.channels_max = 16;
> +		dai->capture.rates = OMAP_MCBSP_RATES;
> +		if (mcbsp->pdata->reg_size == 2)
> +			dai->capture.formats = SNDRV_PCM_FMTBIT_S16_LE;
> +		else
> +			dai->capture.formats = SNDRV_PCM_FMTBIT_S16_LE |
> +					       SNDRV_PCM_FMTBIT_S32_LE;
> +	}
> +
> +	return 0;
> +}
>   
>   static const struct snd_soc_component_driver omap_mcbsp_component = {
>   	.name		= "omap-mcbsp",
> @@ -1404,18 +1435,17 @@ static int asoc_mcbsp_probe(struct platform_device *pdev)
>   	mcbsp->dev = &pdev->dev;
>   	platform_set_drvdata(pdev, mcbsp);
>   
> -	ret = omap_mcbsp_init(pdev);
> +	ret = omap_mcbsp_init_dais(mcbsp);
>   	if (ret)
>   		return ret;
>   
> -	if (mcbsp->pdata->reg_size == 2) {
> -		omap_mcbsp_dai.playback.formats = SNDRV_PCM_FMTBIT_S16_LE;
> -		omap_mcbsp_dai.capture.formats = SNDRV_PCM_FMTBIT_S16_LE;
> -	}
> +	ret = omap_mcbsp_init(pdev);
> +	if (ret)
> +		return ret;
>   
>   	ret = devm_snd_soc_register_component(&pdev->dev,
>   					      &omap_mcbsp_component,
> -					      &omap_mcbsp_dai, 1);
> +					      mcbsp->dais, mcbsp->dai_count);
>   	if (ret)
>   		return ret;
>   
> 

-- 
Péter

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Péter Ujfalusi <peter.ujfalusi@gmail.com> [210126 06:00]:
> On 1/24/21 11:27 AM, Pavel Machek wrote:
> > From: Tony Lindgren <tony@atomide.com>
> > +	for (i = 0; i < mcbsp->dai_count; i++) {
> > +		struct snd_soc_dai_driver *dai = &mcbsp->dais[i];
> > +
> > +		dai->name = devm_kasprintf(mcbsp->dev, GFP_KERNEL, "%s-dai%i",
> > +					   dev_name(mcbsp->dev), i);
> > +
> > +		if (i == 0) {
> > +			dai->probe = omap_mcbsp_probe;
> > +			dai->remove = omap_mcbsp_remove;
> > +			dai->ops = &mcbsp_dai_ops;
> > +		}
> 
> You are effectively creating extra dummy-dais (no ops), but naming them as
> McBSP.
> The dummy-dais will only work if the real dai is in use and the dai link
> which contains the real dai must be configured (TDM slots, format, channels)
> to accomodate the link which contains the dummy-dai.
> 
> The idea did not aged well for me ;)
> It still looks and sounds like a hack to model the TDM slots on a single DAI
> as multiple DAIs just to satisfy a generic binding which is not aimed to
> satisfy the droid4 setup (which is far from anything simple).

After thinking about this a bit more, I think the voice call dai should be
created by the voice dai. When we have an active voice call, the data
transfer is completely out of control of the kernel mcbsp driver. It needs
to be only configured on the pmic.

So I'm suggesting tha we create the modem voice call dai as a child for
sound/soc/codecs/cpcap.c, does that sound OK to you guys?

I think from snd-soc-audio-graph-card binding point of view, we'd just move
the cpu_dai_mdm endpoint out of the mcbsp in the device tree and drop the
$subject patch. Then the dts for the pmic voice codec becomes something
like this (untested):

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@0 {
		};
		cpu_dai_mdm: endpoint@1 {
			reg = <1>;
			dai-format = "dsp_a";
			frame-master = <&cpcap_audio_codec1>;
			bitclock-master = <&cpcap_audio_codec1>;
			remote-endpoint = <&mot_mdm6600_audio_codec0>;
		};
        };
};

For things like recording a voice call, I think mcbsp could be configured
to also listen on the traffic and dump it out. I guess that could also
happen directly with calls from the sound/soc/codecs/cpcap.c driver to
the mcbsp driver since we havethe audio graph mapping. Anyways, that's a
separate series of patches, still something to consider.

Regards,

Tony

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [200221 13:21]:
> Hi Tony,
> 
> On 20/02/2020 22.15, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:16]:
> >> On 18/02/2020 23.16, Sebastian Reichel wrote:
> >>> I suppose in the end its a question if generic card can provide TDM
> >>> support.
> >>
> >> 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.
> > 
> > Well I guess the key thing to check here is if it's enough to
> > keep track of things in the cpcap codec driver. If cpcap is always
> > involved, that should be sufficient.
> 
> The codec driver should keep track on what it can do, but should not
> start policing the outside world.
> The machine driver knows the connections and should tell the components
> on what to do.

OK that makes senes to me. So I guess now the question is if
we can maintain this state in snd-soc-audio-graph-card instead
of needing a custom machine driver.

Regards,

Tony

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

Hi Tony,

On 20/02/2020 22.13, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:08]:
>> On 18/02/2020 17.28, Tony Lindgren wrote:
>>> Right. I'm not attached to the dummy dai, but looks like currently
>>> snd-soc-audio-graph-card won't work without it.
>>
>> The generic cards will link up a dummy dai/codec when it is needed by DPMC.
> 
> Not sure what should be fixed here..

The ASoC core creates dummy codec and dummy dai. They can be used by
machine drivers when there is a need for a dummy connection.

>>> And we potentially
>>> do need a place to configure TDM slot specific stuff for mcbsp.
>>
>> Yes, but you still have one port and one endpoint should not change the
>> configuration which is already in used for the other endpoint.
> 
> OK so what's the fix for snd-soc-audio-graph-card expecting a
> separate DAI then?

If it expects separate DAI in place where you don't actually have a DAI
then it should use the dummy dai.

>>> Oh, I think there are Android apps to do that though.. Never tried
>>> if they work on droid4. But if they do, doing a register dump of
>>> mcbsp3 would show up how it's configured.
>>
>> I don't see how you could record the data from the line which is
>> connected to McBSP_DX pin (the pin is output).
>>
>> But I might be missing something.
> 
> Yeah I don't know either, but the pins we have muxed for
> mcbsp3 are:
> 
> /* 0x4a100106 abe_pdm_ul_data.abe_mcbsp3_dr ag25 */
> OMAP4_IOPAD(0x106, PIN_INPUT | MUX_MODE1)
> 
> /* 0x4a100108 abe_pdm_dl_data.abe_mcbsp3_dx af25 */
> OMAP4_IOPAD(0x108, PIN_OUTPUT | MUX_MODE1)
> 
> /* 0x4a10010a abe_pdm_frame.abe_mcbsp3_clkx ae25 */
> OMAP4_IOPAD(0x10a, PIN_INPUT | MUX_MODE1)
> 
> /* 0x4a10010c abe_pdm_lb_clk.abe_mcbsp3_fsx af26 */
> OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1)
> 
> Isn't the data receive there as mcbsp3_dr?

Yes, that's the one. _dx is the tx pin from McBSP pow.

>>> I think the link for the patches you posted is patching the
>>> snd-soc-audio-graph-card already?
>>
>> Yes it does, but the functionality is there via custom machine drivers.
>> What I afraid is that such a complex wiring as the Droid4 have it might
>> be not possible to use a generic - fits everything - driver without
>> making it a customized one ;)
>>
>> Otho, if the only thing is the machine level DAPM switching and linking
>> the paths then it might be relatively straight forward to extend the
>> simple-card family.
> 
> Yeah or maybe it just needs to be handled directly in the cpcap,
> mdm6600 codec drivers?

The cpcap driver should no nothing about mdm6600 or anything which is
outside of it, similarly to mdm6600.
The machine driver knows that in the driod4 you have McBSP2, McBSP3,
CPCAP, MDM6600 and WL1285. It is the role of the machine driver to make
these work together.

>>> Right. So right now it seems that for snd-soc-audio-graph-card
>>> needs the dummy dai, but it's unclear what would need to be
>>> changed to not use a dummy dai for mcbsp.
>>
>> Since simple-card family can and will connect up dummy dai/codec when
>> needed based on the setup, I would look at that and make it do so.
> 
> Oh so make simple-card spin up the dummy dai instead of mcbsp?

Not really, we have dummy dai/codec from core, the machine driver should
use them.

Just think about: what if you move the audio setup to a new board with
am5 for example? You will have McASP in place of McBSP, so you will also
patch it up to create dummy mcasp dais?
What if you move the setup to Tegra or imx, or qc? Patch everything up
to create dummy dais?

>>> The dts snippets I posted earlier do follow the graph bindings
>>> as far as I know. But just to confirm, do you see any need to
>>> move things around there?
>>
>> It also states that a port is a physical port which can have multiple
>> endpoints. But multiple endpoint != DAI. port == dai.
> 
> I guess I'm getting really confused now.. Are you saying
> the dts needs to be changed too now?

In a graph the port is the DAI. We have only one port in McBSP and it is
bi-directional (dr/dx pins + clk lines).

Usually you have one McBSP connected to one codec, graph is clean: port
to port.

In droid4 the physical lines are connecting together the 4 ports:
McBSP3, CPCAP_voice, MDM6600 and Wl1285, right?
It is a web ;)

But you still have _one_ port on the McBSP3 and not three. I guess the
endpoints are coming into picture at this point to represent that the
port is connected to multiple ports.
The endpoints should control the port which is their parent.

mcbsp3_port {
	reg = <0>;
	mcbsp3_ep0: endpoint0 { remote-endpoint = <&cpcap_voice_ep0>; };
	mcbsp3_ep1: endpoint1 { remote-endpoint = <&dmd6600_ep0>; };
	mcbsp3_ep2: endpoint2 { remote-endpoint = <&wl1285_ep0>; };
};

cpcap_voice_port {
	reg = <0>;
	cpcap_voice_ep0: endpoint0 { remote-endpoint = <&mcbsp3_ep0>; };
	cpcap_voice_ep1: endpoint1 { remote-endpoint = <&dmd6600_ep1>;};
	cpcap_voice_ep2: endpoint2 { remote-endpoint = <&wl1285_ep1>; };
};

Or something...

If the cpcap_voice_ep1 <-> dmd6600_ep1 link is enabled then the McBSP3
port is not, it is not part of the graph.

In any case you will need DPCM for this to work to push the needed
parameters to the codecs in case of codec2codec connection.

> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

Hi Tony,

On 20/02/2020 22.15, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:16]:
>> On 18/02/2020 23.16, Sebastian Reichel wrote:
>>> I suppose in the end its a question if generic card can provide TDM
>>> support.
>>
>> 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.
> 
> Well I guess the key thing to check here is if it's enough to
> keep track of things in the cpcap codec driver. If cpcap is always
> involved, that should be sufficient.

The codec driver should keep track on what it can do, but should not
start policing the outside world.
The machine driver knows the connections and should tell the components
on what to do.

> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

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.
> 
> 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.
> > 
> > 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?
> > 
> >> 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?
> > 
> > I provided CPCAP registers for BT call, which should be enough to
> > figure this out (I did not yet analyze the results myself).
> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:16]:
> On 18/02/2020 23.16, Sebastian Reichel wrote:
> > I suppose in the end its a question if generic card can provide TDM
> > support.
> 
> 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.

Well I guess the key thing to check here is if it's enough to
keep track of things in the cpcap codec driver. If cpcap is always
involved, that should be sufficient.

Regards,

Tony

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [200220 14:08]:
> On 18/02/2020 17.28, Tony Lindgren wrote:
> > Right. I'm not attached to the dummy dai, but looks like currently
> > snd-soc-audio-graph-card won't work without it.
> 
> The generic cards will link up a dummy dai/codec when it is needed by DPMC.

Not sure what should be fixed here..

> > And we potentially
> > do need a place to configure TDM slot specific stuff for mcbsp.
> 
> Yes, but you still have one port and one endpoint should not change the
> configuration which is already in used for the other endpoint.

OK so what's the fix for snd-soc-audio-graph-card expecting a
separate DAI then?

> > Oh, I think there are Android apps to do that though.. Never tried
> > if they work on droid4. But if they do, doing a register dump of
> > mcbsp3 would show up how it's configured.
> 
> I don't see how you could record the data from the line which is
> connected to McBSP_DX pin (the pin is output).
> 
> But I might be missing something.

Yeah I don't know either, but the pins we have muxed for
mcbsp3 are:

/* 0x4a100106 abe_pdm_ul_data.abe_mcbsp3_dr ag25 */
OMAP4_IOPAD(0x106, PIN_INPUT | MUX_MODE1)

/* 0x4a100108 abe_pdm_dl_data.abe_mcbsp3_dx af25 */
OMAP4_IOPAD(0x108, PIN_OUTPUT | MUX_MODE1)

/* 0x4a10010a abe_pdm_frame.abe_mcbsp3_clkx ae25 */
OMAP4_IOPAD(0x10a, PIN_INPUT | MUX_MODE1)

/* 0x4a10010c abe_pdm_lb_clk.abe_mcbsp3_fsx af26 */
OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1)

Isn't the data receive there as mcbsp3_dr?

> > I think the link for the patches you posted is patching the
> > snd-soc-audio-graph-card already?
> 
> Yes it does, but the functionality is there via custom machine drivers.
> What I afraid is that such a complex wiring as the Droid4 have it might
> be not possible to use a generic - fits everything - driver without
> making it a customized one ;)
> 
> Otho, if the only thing is the machine level DAPM switching and linking
> the paths then it might be relatively straight forward to extend the
> simple-card family.

Yeah or maybe it just needs to be handled directly in the cpcap,
mdm6600 codec drivers?

> > Right. So right now it seems that for snd-soc-audio-graph-card
> > needs the dummy dai, but it's unclear what would need to be
> > changed to not use a dummy dai for mcbsp.
> 
> Since simple-card family can and will connect up dummy dai/codec when
> needed based on the setup, I would look at that and make it do so.

Oh so make simple-card spin up the dummy dai instead of mcbsp?

> > The dts snippets I posted earlier do follow the graph bindings
> > as far as I know. But just to confirm, do you see any need to
> > move things around there?
> 
> It also states that a port is a physical port which can have multiple
> endpoints. But multiple endpoint != DAI. port == dai.

I guess I'm getting really confused now.. Are you saying
the dts needs to be changed too now?

Regards,

Tony

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

Hi Sebastian,

On 18/02/2020 23.16, Sebastian Reichel wrote:
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
> 
> Your description matches my understanding of the hardware setup.
> 
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
>>
>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 	1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 	2.1: to CPCAP_voice
>> 	2.2: to WL1285
>> CPCAP: 2 ports
>> 	hifi:	3.1: to McBSP2
>> 	voice:	4.1: to McBSP3
>> 		4.2: to MDM6600
>> MDM6600: 2 ports
> 
> I suppose you mean 1 port, 2 endpoints?

Oh yes. Numbers....

> 
>> 	5.1: to CPAC_voice
>> 	5.2: to WL1285
>> WL1285: 2 ports
> 
> and here too?

here too ;)

> 
>> 	6.1: to McBSP3
>> 	6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
>>
>> Can a generic card provide such a functionality?
> 
> I suppose in the end its a question if generic card can provide TDM
> support.

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.

>> In case of B/C you should not have a running stream imho.
> 
> 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?
> 
>> 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?
> 
> I provided CPCAP registers for BT call, which should be enough to
> figure this out (I did not yet analyze the results myself).

I got the datasheet from NXP (thanks for the pointer!), I try to look at
it in a coming days.

>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
> 
> Makes sense to me.
> 
> -- Sebastian
- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

On 18/02/2020 17.28, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 12:44]:
>> Hi Tony,
>>
>> On 18/02/2020 1.10, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>>>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>>>> and everything happens betwee the modem and the cpcap pmic.
>>>>
>>>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>>>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>>>> or McPDM...
>>>>
>>>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
>>>
>>> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
>>> mcbsp for voice call.
>>>
>>> According to Sebastian sounds like mcbsp can be idle at that point.
>>>
>>> But what about capture of voice call at the mcbsp from the
>>> TDM slot? In that case mcbsp would be active.
>>
>> Sure, but with the dummy dai it won't....
> 
> Right. I'm not attached to the dummy dai, but looks like currently
> snd-soc-audio-graph-card won't work without it.

The generic cards will link up a dummy dai/codec when it is needed by DPMC.

> And we potentially
> do need a place to configure TDM slot specific stuff for mcbsp.

Yes, but you still have one port and one endpoint should not change the
configuration which is already in used for the other endpoint.

>> If I understand correctly the HW setup:
>> McBSP2 -> CPCAP_hifi (only playback)
>>
>> CPCAP_voice is the i2s clock master.
>> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
>> i2s lines.
>>
>> In case of Voice call with analog mic/speaker only CPCAP_voice and
>> MDM6600 is used.
>> In case of Voice call with BT only MDM6600 and WL1285 is used (but
>> CPCAP_voice must provide the clocks?)
> 
> Yes my guess is cpcap voice is the clock master in that case.
> It should show up from the cpcap register dump from Android with
> audio playing to a bluetooth headset.

OK.

>> In case you would have any algorithm running on OMAP4 for the calls,
>> then you will have McBSP3 inserted and used between MDM6600 and
>> CPAC_voice/WL1285.
>> Similarly, if you would like to tap in and record the data from the bus
>> you will have McBSP3 enabled.
>>
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
>>
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
> 
> Oh, I think there are Android apps to do that though.. Never tried
> if they work on droid4. But if they do, doing a register dump of
> mcbsp3 would show up how it's configured.

I don't see how you could record the data from the line which is
connected to McBSP_DX pin (the pin is output).

But I might be missing something.

>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 	1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 	2.1: to CPCAP_voice
>> 	2.2: to WL1285
>> CPCAP: 2 ports
>> 	hifi:	3.1: to McBSP2
>> 	voice:	4.1: to McBSP3
>> 		4.2: to MDM6600
>> MDM6600: 2 ports
>> 	5.1: to CPAC_voice
>> 	5.2: to WL1285
>> WL1285: 2 ports
>> 	6.1: to McBSP3
>> 	6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
> 
> OK
> 
>> Can a generic card provide such a functionality?
> 
> I think the link for the patches you posted is patching the
> snd-soc-audio-graph-card already?

Yes it does, but the functionality is there via custom machine drivers.
What I afraid is that such a complex wiring as the Droid4 have it might
be not possible to use a generic - fits everything - driver without
making it a customized one ;)

Otho, if the only thing is the machine level DAPM switching and linking
the paths then it might be relatively straight forward to extend the
simple-card family.

>> In case of B/C you should not have a running stream imho.
>> 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?
> 
> Yeah, no idea.. But that's easy to configure in the dts based on
> the graph bindings :)

Yep, indeed.

>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
> 
> Right. So right now it seems that for snd-soc-audio-graph-card
> needs the dummy dai, but it's unclear what would need to be
> changed to not use a dummy dai for mcbsp.

Since simple-card family can and will connect up dummy dai/codec when
needed based on the setup, I would look at that and make it do so.

> The dts snippets I posted earlier do follow the graph bindings
> as far as I know. But just to confirm, do you see any need to
> move things around there?

It also states that a port is a physical port which can have multiple
endpoints. But multiple endpoint != DAI. port == dai.

>>>>>>>> I know it was discussed, but can not find the mail:
>>>>>>>> Can you brief again on the audio connection?
>>>>>>>
>>>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>>>> the audio connection:
>>>>>>>
>>>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>>>
>>>>>> Thanks!
>>>>>>  
>>>>>>>> Do you have branch with working code?
>>>>>>>
>>>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>>>> kernel.org git branch with voice calls working.
>>>>>>
>>>>>> I think I should put my droid4 out and try to get it working...
>>>>>> Do you have a link for dummies to follow to get started? ;)
>>>>>
>>>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>>>> test image using v5.5 kernel + modem and audio patches:
>>>>>
>>>>> https://leste.maemo.org/Motorola_Droid_4
>>>>>
>>>>> Just use a decent speed micro-sd card rated "a1" for example.
>>>>
>>>> Cool. Now I can dual boot the droid4 :D
>>>> I needed to rewrite the /etc/shadow to get a known root password so I
>>>> can log in.
>>>
>>> Not sure if you mean password for the droid4-kexecboot or the
>>> Linux distro you installed..
>>
>> It was for the maemo-leste.
>> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
>> reference image...
> 
> Gentoo cool :)
> 
> I've had good luck with just plain alpine armv7 edge, the package
> updates work very fast for a slow system. The musl stuff requires
> running stellarium with 3d acceleration in a minimal devuan or
> whatever chroot environment though for stellarium etc..

I see, I might go via the lazy route and take buildroot ;)

>>> But for droid4-kexecboot, you
>>> can configure it to automatically download new kernels over wlan.
>>> There's some info on the machine specific password and how to
>>> configure wlan in the droid4-kexecboot buildroot commits here:
>>>
>>> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
>>>
>>>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>>>> the /boot/boot/boot.cfg to boot my kernel, right?
>>>
>>> Yeah you can update kernels and modules over wlan from the distro(s)
>>> you have configured, and also from droid4-kexecboot as above.
>>
>> I need to try droid4-kexecboot's wifi support then.
> 
> Yeah you need to configure wpa_supplicant.conf and wlan.conf or
> whatever it was called. And make sure you have copied the old
> stock v3.0.8 kernel wlan modules and firmware as mentioned in
> the droid4-kexecboot git readme and install files.

OK.

> Oh, and also read about the flags you need to use for mkfs.ext4 if
> doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand
> all the new flags if you want a partition to be readable for the
> droid4-kexecboot bootloader. And also the all the old Android
> distros currently still stuck with the ancient v3.0.8 kernel :p

I see, thanks for the warning!

> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 6292 bytes --]

Hi,

On Tue, Feb 18, 2020 at 02:43:19PM +0200, Peter Ujfalusi wrote:
> On 18/02/2020 1.10, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
> >> On 14/02/2020 19.03, Tony Lindgren wrote:
> >>> But right now in droid4 voice call case mcbsp is just the i2s transport,
> >>> and everything happens betwee the modem and the cpcap pmic.
> >>
> >> Iow you don't need McBSP DAI at all. If you would have added the dummy
> >> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
> >> or McPDM...
> >>
> >> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
> > 
> > Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
> > mcbsp for voice call.
> > 
> > According to Sebastian sounds like mcbsp can be idle at that point.
> > 
> > But what about capture of voice call at the mcbsp from the
> > TDM slot? In that case mcbsp would be active.
> 
> Sure, but with the dummy dai it won't....
> 
> If I understand correctly the HW setup:
> McBSP2 -> CPCAP_hifi (only playback)
>
> CPCAP_voice is the i2s clock master.
> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
> i2s lines.
> 
> In case of Voice call with analog mic/speaker only CPCAP_voice and
> MDM6600 is used.
> In case of Voice call with BT only MDM6600 and WL1285 is used (but
> CPCAP_voice must provide the clocks?)
> In case you would have any algorithm running on OMAP4 for the calls,
> then you will have McBSP3 inserted and used between MDM6600 and
> CPAC_voice/WL1285.
> Similarly, if you would like to tap in and record the data from the bus
> you will have McBSP3 enabled.
> 
> The simplest use cases you want to support:
> A. McBSP3 <-> CPCAP_voice (playback/capture)
> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
> C. MDM6600 <-> WL1285 (BT voice call)
> D. McBSP3 <-> BT (VoIP?)

Your description matches my understanding of the hardware setup.

> I would not bother with recording the call as you would need tom
> reconfigure the McBSP playback pin (is it even possible) as input to
> OMAP4, I think..
> 
> B/C is codec2codec, McBSP3 is not involved at all.
> A/D is when McBSP3 is used only.
> 
> Imho this can be represented as
> McBSP2: 1 port
> 	1.1: to CPCAP_hifi
> 
> McBSP3: 1 port, 2 endpoint
> 	2.1: to CPCAP_voice
> 	2.2: to WL1285
> CPCAP: 2 ports
> 	hifi:	3.1: to McBSP2
> 	voice:	4.1: to McBSP3
> 		4.2: to MDM6600
> MDM6600: 2 ports

I suppose you mean 1 port, 2 endpoints?

> 	5.1: to CPAC_voice
> 	5.2: to WL1285
> WL1285: 2 ports

and here too?

> 	6.1: to McBSP3
> 	6.2: to MDM6600
> 
> The machine driver should switch between the graph links based on the
> use case for the interconnected devices:
> A: 2.2 <-> 4.1
> B: 4.2 <-> 5.1
> C: 6.2 <-> 5.1
> D: 2.2 <-> 6.1
> 
> Can a generic card provide such a functionality?

I suppose in the end its a question if generic card can provide TDM
support.

> In case of B/C you should not have a running stream imho.

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?

> 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?

I provided CPCAP registers for BT call, which should be enough to
figure this out (I did not yet analyze the results myself).

> I'm not sure if we should span out dummy dais for endpoints within a
> port. Imho the port _is_ the dai. Different endpoints might use
> different TDM slots on the port (or the same slot, which makes them
> exclusive).

Makes sense to me.

-- Sebastian

> >>>>>> I know it was discussed, but can not find the mail:
> >>>>>> Can you brief again on the audio connection?
> >>>>>
> >>>>> Below is a link to a mailing list thread where Sebastian describes
> >>>>> the audio connection:
> >>>>>
> >>>>> https://lkml.org/lkml/2018/3/28/881
> >>>>
> >>>> Thanks!
> >>>>  
> >>>>>> Do you have branch with working code?
> >>>>>
> >>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
> >>>>> kernel.org git branch with voice calls working.
> >>>>
> >>>> I think I should put my droid4 out and try to get it working...
> >>>> Do you have a link for dummies to follow to get started? ;)
> >>>
> >>> Probably the easiest one to use right now is the Maemo-leste devuan based
> >>> test image using v5.5 kernel + modem and audio patches:
> >>>
> >>> https://leste.maemo.org/Motorola_Droid_4
> >>>
> >>> Just use a decent speed micro-sd card rated "a1" for example.
> >>
> >> Cool. Now I can dual boot the droid4 :D
> >> I needed to rewrite the /etc/shadow to get a known root password so I
> >> can log in.
> > 
> > Not sure if you mean password for the droid4-kexecboot or the
> > Linux distro you installed..
> 
> It was for the maemo-leste.
> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
> reference image...
> 
> > But for droid4-kexecboot, you
> > can configure it to automatically download new kernels over wlan.
> > There's some info on the machine specific password and how to
> > configure wlan in the droid4-kexecboot buildroot commits here:
> > 
> > https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
> > 
> >> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
> >> the /boot/boot/boot.cfg to boot my kernel, right?
> > 
> > Yeah you can update kernels and modules over wlan from the distro(s)
> > you have configured, and also from droid4-kexecboot as above.
> 
> I need to try droid4-kexecboot's wifi support then.
> 
> > And note that kexecboot looks for a boot/boot.cfg file to use on
> > every usable parition it finds and uses all the found entries
> > based on the priority configured for the boot.cfg entry.
> 
> OK, thanks!
> 
> > 
> > Regards,
> > 
> > Tony
> > 
> 
> - Péter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 3525 bytes --]

Hi,

On Tue, Feb 18, 2020 at 06:19:05AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sebastian.reichel@collabora.com> [200218 06:05]:
> > On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
> > > * Sebastian Reichel <sre@kernel.org> [200214 13:05]:
> > > > On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
> > > > > And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio
> > > > > above.
> > > > 
> > > > My understanding is, that CPU is not involved for calls (except for
> > > > setting up cpcap registers correctly). Basically McBSP3 should
> > > > remain idle for a call and data goes directly from modem to cpcap.
> > > > The same should work for modem <-> BT, except that CPCAP seems to
> > > > always provide the clock. That would imply a direct link between
> > > > modem and codec / BT?
> > > 
> > > Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during
> > > voice call though, I guess it should be doable since mcbsp is not
> > > the clock master :)
> > > 
> > > > > 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 can provider register values once I find some time.
> > 
> > [NI] Normal idle (no BT headset connected)
> > [BI] Bluetooth idle (with BT headset connected)
> > [BC] Bluetooth call in progress
> > [NC] Normal call in progress (BT headset disabled)
> > 
> >                      [NI]  =>  [BI]  =>  [BC]  =>  [NC]
> > CPCAP_REG_VAUDIOC   0x0065 => 0x0065 => 0x0065 => 0x0025
> > CPCAP_REG_CC        0x0000 => 0x0000 => 0x6000 => 0x60df
> > CPCAP_REG_CDI       0x0040 => 0x0000 => 0xaa40 => 0xae0a
> > CPCAP_REG_SDAC      -------------- 0x0000 --------------
> > CPCAP_REG_SDACDI    -------------- 0x0004 --------------
> > CPCAP_REG_TXI       0x0804 => 0x0004 => 0x0000 => 0x0cc6
> > CPCAP_REG_TXMP      0x079c => 0x079c => 0x0400 => 0x0673
> > CPCAP_REG_RXOA      0x0000 => 0x0000 => 0x0001 => 0x0001
> > CPCAP_REG_RXVC      0x0d34 => 0x0d34 => 0x0000 => 0x0b2c
> > CPCAP_REG_RXCOA     0x0000 => 0x0000 => 0x0000 => 0x0601
> > CPCAP_REG_RXSDOA    0x0000 => 0x0000 => 0x0600 => 0x0600
> > CPCAP_REG_RXEPOA    -------------- 0x0400 --------------
> > CPCAP_REG_RXLL      -------------- 0x0000 --------------
> > CPCAP_REG_A2LA      -------------- 0x0030 --------------
> > CPCAP_REG_MIPIS1    -------------- 0x0000 --------------
> > CPCAP_REG_MIPIS2    -------------- 0x0000 --------------
> > CPCAP_REG_MIPIS3    -------------- 0x0000 --------------
> > CPCAP_REG_LVAB      -------------- 0x0000 --------------
> 
> Great thanks! Care to do also a dump just playing music to on
> bluetooth headset at some point?

AFAIK BT music is usually done via A2DP using the data connection,
but I can get a register dump to make sure. I guess the more
interesting bit would be to use BT headset for a VOIP call, which
requires the headset profile being routed to the CPU.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 15:28]:
> 
> 
> On 18/02/2020 1.36, Tony Lindgren wrote:
> > * Tony Lindgren <tony@atomide.com> [200217 23:10]:
> >> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
> >>> On 14/02/2020 19.03, Tony Lindgren wrote:
> >>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
> >>>> and everything happens betwee the modem and the cpcap pmic.
> >>>
> >>> Iow you don't need McBSP DAI at all. If you would have added the dummy
> >>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
> >>> or McPDM...
> >>>
> >>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
> >>
> >> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
> >> mcbsp for voice call.
> >>
> >> According to Sebastian sounds like mcbsp can be idle at that point.
> >>
> >> But what about capture of voice call at the mcbsp from the
> >> TDM slot? In that case mcbsp would be active.
> > 
> > Looks like only initializing only one mcbsp3 instance here
> > instead of two will produce an oops as below.
> > 
> > I'm not sure how this is supposed to work for
> > snd-soc-audio-graph-card with multipe endpoints connected
> > to just one mcbsp dai instance?
> > 
> > Regards,
> > 
> > Tony
> > 
> > 8< -------------------
> What is the kernel version?
> The context is missing...
> Who printed the line:
> dev_err(dev, "ASoC: Failed to register DAIs: %d\n", ret);

Oh sorry, this was just a quick test with droid4-pending-v5.5 branch
with only one mcbsp dai initialized.

> This is only possible if snd_soc_component_initialize() fail, which can
> only fail if snd_soc_component_unique_name() fails.
> 
> > Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> > snd_soc_del_component_unlocked+0xf4/0x110
> 
> Not too helpful ;)

Yeah I have not looked at it closer so far..

Regards,

Tony

> > ...
> > [   39.616027] Backtrace:
> > [   39.616149] [<bf3f6bc4>] (snd_soc_del_component_unlocked [snd_soc_core]) from [<bf3f8ff4>] (snd_soc_add_component+0x238/0x374 [snd_s)
> > [   39.616149]  r7:00000002 r6:00000002 r5:ec9a0e78 r4:00000122
> > [   39.678283] qmi_wwan 1-1:1.6: cdc-wdm1: USB WDM device
> > [   39.739074] [<bf3f8dbc>] (snd_soc_add_component [snd_soc_core]) from [<bf3f9180>] (snd_soc_register_component+0x50/0x60 [snd_soc_cor)
> > [   39.739074]  r10:bf4582d0 r9:ec9d0840 r8:00000002 r7:00000002 r6:ec9d0640 r5:bf4584ac
> > [   39.800842] asoc-audio-graph-card soundcard: using device tree for GPIO lookup
> > [   39.808685]  r4:eed52410
> > [   39.862304] [<bf3f9130>] (snd_soc_register_component [snd_soc_core]) from [<bf4088b4>] (devm_snd_soc_register_component+0x54/0x90 [s)
> > [   39.862304]  r7:ec9d0640 r6:bf4584ac r5:ec9d3040 r4:eed52410
> > [   39.925048] qmi_wwan 1-1:1.6 wwan1: register 'qmi_wwan' at usb-4a064800.ohci-1, WWAN/QMI device, 2e:59:df:3f:4f:ef
> > [   39.984558] [<bf408860>] (devm_snd_soc_register_component [snd_soc_core]) from [<bf456fb8>] (asoc_mcbsp_probe+0x3e8/0x574 [snd_soc_o)
> > [   39.984558]  r9:ec9d0840 r8:ec9f4000 r7:eed52410 r6:00000000 r5:eed52400 r4:ec9d0840
> > [   39.984588] [<bf456bd0>] (asoc_mcbsp_probe [snd_soc_omap_mcbsp]) from [<c068475c>] (platform_drv_probe+0x58/0xa8)
> > [   39.984619]  r10:00000000 r9:0000002e r8:bf459014 r7:00000000 r6:bf459014 r5:00000000
> > [   40.044342] of_get_named_gpiod_flags: can't parse 'pa-gpios' property of node '/soundcard[0]'
> > [   40.051788]  r4:eed52410
> > [   40.100769] [<c0684704>] (platform_drv_probe) from [<c06820ac>] (really_probe+0x1ec/0x358)
> > 
> 
> - Péter
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 12:44]:
> Hi Tony,
> 
> On 18/02/2020 1.10, Tony Lindgren wrote:
> > * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
> >> On 14/02/2020 19.03, Tony Lindgren wrote:
> >>> But right now in droid4 voice call case mcbsp is just the i2s transport,
> >>> and everything happens betwee the modem and the cpcap pmic.
> >>
> >> Iow you don't need McBSP DAI at all. If you would have added the dummy
> >> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
> >> or McPDM...
> >>
> >> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
> > 
> > Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
> > mcbsp for voice call.
> > 
> > According to Sebastian sounds like mcbsp can be idle at that point.
> > 
> > But what about capture of voice call at the mcbsp from the
> > TDM slot? In that case mcbsp would be active.
> 
> Sure, but with the dummy dai it won't....

Right. I'm not attached to the dummy dai, but looks like currently
snd-soc-audio-graph-card won't work without it. And we potentially
do need a place to configure TDM slot specific stuff for mcbsp.

> If I understand correctly the HW setup:
> McBSP2 -> CPCAP_hifi (only playback)
> 
> CPCAP_voice is the i2s clock master.
> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
> i2s lines.
> 
> In case of Voice call with analog mic/speaker only CPCAP_voice and
> MDM6600 is used.
> In case of Voice call with BT only MDM6600 and WL1285 is used (but
> CPCAP_voice must provide the clocks?)

Yes my guess is cpcap voice is the clock master in that case.
It should show up from the cpcap register dump from Android with
audio playing to a bluetooth headset.

> In case you would have any algorithm running on OMAP4 for the calls,
> then you will have McBSP3 inserted and used between MDM6600 and
> CPAC_voice/WL1285.
> Similarly, if you would like to tap in and record the data from the bus
> you will have McBSP3 enabled.
> 
> The simplest use cases you want to support:
> A. McBSP3 <-> CPCAP_voice (playback/capture)
> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
> C. MDM6600 <-> WL1285 (BT voice call)
> D. McBSP3 <-> BT (VoIP?)
> 
> I would not bother with recording the call as you would need tom
> reconfigure the McBSP playback pin (is it even possible) as input to
> OMAP4, I think..

Oh, I think there are Android apps to do that though.. Never tried
if they work on droid4. But if they do, doing a register dump of
mcbsp3 would show up how it's configured.

> B/C is codec2codec, McBSP3 is not involved at all.
> A/D is when McBSP3 is used only.
> 
> Imho this can be represented as
> McBSP2: 1 port
> 	1.1: to CPCAP_hifi
> 
> McBSP3: 1 port, 2 endpoint
> 	2.1: to CPCAP_voice
> 	2.2: to WL1285
> CPCAP: 2 ports
> 	hifi:	3.1: to McBSP2
> 	voice:	4.1: to McBSP3
> 		4.2: to MDM6600
> MDM6600: 2 ports
> 	5.1: to CPAC_voice
> 	5.2: to WL1285
> WL1285: 2 ports
> 	6.1: to McBSP3
> 	6.2: to MDM6600
> 
> The machine driver should switch between the graph links based on the
> use case for the interconnected devices:
> A: 2.2 <-> 4.1
> B: 4.2 <-> 5.1
> C: 6.2 <-> 5.1
> D: 2.2 <-> 6.1

OK

> Can a generic card provide such a functionality?

I think the link for the patches you posted is patching the
snd-soc-audio-graph-card already?

> In case of B/C you should not have a running stream imho.
> 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?

Yeah, no idea.. But that's easy to configure in the dts based on
the graph bindings :)

> I'm not sure if we should span out dummy dais for endpoints within a
> port. Imho the port _is_ the dai. Different endpoints might use
> different TDM slots on the port (or the same slot, which makes them
> exclusive).

Right. So right now it seems that for snd-soc-audio-graph-card
needs the dummy dai, but it's unclear what would need to be
changed to not use a dummy dai for mcbsp.

The dts snippets I posted earlier do follow the graph bindings
as far as I know. But just to confirm, do you see any need to
move things around there?

> >>>>>> I know it was discussed, but can not find the mail:
> >>>>>> Can you brief again on the audio connection?
> >>>>>
> >>>>> Below is a link to a mailing list thread where Sebastian describes
> >>>>> the audio connection:
> >>>>>
> >>>>> https://lkml.org/lkml/2018/3/28/881
> >>>>
> >>>> Thanks!
> >>>>  
> >>>>>> Do you have branch with working code?
> >>>>>
> >>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
> >>>>> kernel.org git branch with voice calls working.
> >>>>
> >>>> I think I should put my droid4 out and try to get it working...
> >>>> Do you have a link for dummies to follow to get started? ;)
> >>>
> >>> Probably the easiest one to use right now is the Maemo-leste devuan based
> >>> test image using v5.5 kernel + modem and audio patches:
> >>>
> >>> https://leste.maemo.org/Motorola_Droid_4
> >>>
> >>> Just use a decent speed micro-sd card rated "a1" for example.
> >>
> >> Cool. Now I can dual boot the droid4 :D
> >> I needed to rewrite the /etc/shadow to get a known root password so I
> >> can log in.
> > 
> > Not sure if you mean password for the droid4-kexecboot or the
> > Linux distro you installed..
> 
> It was for the maemo-leste.
> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
> reference image...

Gentoo cool :)

I've had good luck with just plain alpine armv7 edge, the package
updates work very fast for a slow system. The musl stuff requires
running stellarium with 3d acceleration in a minimal devuan or
whatever chroot environment though for stellarium etc..

> > But for droid4-kexecboot, you
> > can configure it to automatically download new kernels over wlan.
> > There's some info on the machine specific password and how to
> > configure wlan in the droid4-kexecboot buildroot commits here:
> > 
> > https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
> > 
> >> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
> >> the /boot/boot/boot.cfg to boot my kernel, right?
> > 
> > Yeah you can update kernels and modules over wlan from the distro(s)
> > you have configured, and also from droid4-kexecboot as above.
> 
> I need to try droid4-kexecboot's wifi support then.

Yeah you need to configure wpa_supplicant.conf and wlan.conf or
whatever it was called. And make sure you have copied the old
stock v3.0.8 kernel wlan modules and firmware as mentioned in
the droid4-kexecboot git readme and install files.

Oh, and also read about the flags you need to use for mkfs.ext4 if
doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand
all the new flags if you want a partition to be readable for the
droid4-kexecboot bootloader. And also the all the old Android
distros currently still stuck with the ancient v3.0.8 kernel :p

Regards,

Tony

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

On 18/02/2020 1.36, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [200217 23:10]:
>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>>> and everything happens betwee the modem and the cpcap pmic.
>>>
>>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>>> or McPDM...
>>>
>>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
>>
>> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
>> mcbsp for voice call.
>>
>> According to Sebastian sounds like mcbsp can be idle at that point.
>>
>> But what about capture of voice call at the mcbsp from the
>> TDM slot? In that case mcbsp would be active.
> 
> Looks like only initializing only one mcbsp3 instance here
> instead of two will produce an oops as below.
> 
> I'm not sure how this is supposed to work for
> snd-soc-audio-graph-card with multipe endpoints connected
> to just one mcbsp dai instance?
> 
> Regards,
> 
> Tony
> 
> 8< -------------------
What is the kernel version?
The context is missing...
Who printed the line:
dev_err(dev, "ASoC: Failed to register DAIs: %d\n", ret);

This is only possible if snd_soc_component_initialize() fail, which can
only fail if snd_soc_component_unique_name() fails.

> Internal error: Oops: 805 [#1] PREEMPT SMP ARM
> snd_soc_del_component_unlocked+0xf4/0x110

Not too helpful ;)

> ...
> [   39.616027] Backtrace:
> [   39.616149] [<bf3f6bc4>] (snd_soc_del_component_unlocked [snd_soc_core]) from [<bf3f8ff4>] (snd_soc_add_component+0x238/0x374 [snd_s)
> [   39.616149]  r7:00000002 r6:00000002 r5:ec9a0e78 r4:00000122
> [   39.678283] qmi_wwan 1-1:1.6: cdc-wdm1: USB WDM device
> [   39.739074] [<bf3f8dbc>] (snd_soc_add_component [snd_soc_core]) from [<bf3f9180>] (snd_soc_register_component+0x50/0x60 [snd_soc_cor)
> [   39.739074]  r10:bf4582d0 r9:ec9d0840 r8:00000002 r7:00000002 r6:ec9d0640 r5:bf4584ac
> [   39.800842] asoc-audio-graph-card soundcard: using device tree for GPIO lookup
> [   39.808685]  r4:eed52410
> [   39.862304] [<bf3f9130>] (snd_soc_register_component [snd_soc_core]) from [<bf4088b4>] (devm_snd_soc_register_component+0x54/0x90 [s)
> [   39.862304]  r7:ec9d0640 r6:bf4584ac r5:ec9d3040 r4:eed52410
> [   39.925048] qmi_wwan 1-1:1.6 wwan1: register 'qmi_wwan' at usb-4a064800.ohci-1, WWAN/QMI device, 2e:59:df:3f:4f:ef
> [   39.984558] [<bf408860>] (devm_snd_soc_register_component [snd_soc_core]) from [<bf456fb8>] (asoc_mcbsp_probe+0x3e8/0x574 [snd_soc_o)
> [   39.984558]  r9:ec9d0840 r8:ec9f4000 r7:eed52410 r6:00000000 r5:eed52400 r4:ec9d0840
> [   39.984588] [<bf456bd0>] (asoc_mcbsp_probe [snd_soc_omap_mcbsp]) from [<c068475c>] (platform_drv_probe+0x58/0xa8)
> [   39.984619]  r10:00000000 r9:0000002e r8:bf459014 r7:00000000 r6:bf459014 r5:00000000
> [   40.044342] of_get_named_gpiod_flags: can't parse 'pa-gpios' property of node '/soundcard[0]'
> [   40.051788]  r4:eed52410
> [   40.100769] [<c0684704>] (platform_drv_probe) from [<c06820ac>] (really_probe+0x1ec/0x358)
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Sebastian Reichel <sebastian.reichel@collabora.com> [200218 06:05]:
> Hi,
> 
> On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
> > * Sebastian Reichel <sre@kernel.org> [200214 13:05]:
> > > On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
> > > > And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio
> > > > above.
> > > 
> > > My understanding is, that CPU is not involved for calls (except for
> > > setting up cpcap registers correctly). Basically McBSP3 should
> > > remain idle for a call and data goes directly from modem to cpcap.
> > > The same should work for modem <-> BT, except that CPCAP seems to
> > > always provide the clock. That would imply a direct link between
> > > modem and codec / BT?
> > 
> > Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during
> > voice call though, I guess it should be doable since mcbsp is not
> > the clock master :)
> > 
> > > > 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 can provider register values once I find some time.
> 
> [NI] Normal idle (no BT headset connected)
> [BI] Bluetooth idle (with BT headset connected)
> [BC] Bluetooth call in progress
> [NC] Normal call in progress (BT headset disabled)
> 
>                      [NI]  =>  [BI]  =>  [BC]  =>  [NC]
> CPCAP_REG_VAUDIOC   0x0065 => 0x0065 => 0x0065 => 0x0025
> CPCAP_REG_CC        0x0000 => 0x0000 => 0x6000 => 0x60df
> CPCAP_REG_CDI       0x0040 => 0x0000 => 0xaa40 => 0xae0a
> CPCAP_REG_SDAC      -------------- 0x0000 --------------
> CPCAP_REG_SDACDI    -------------- 0x0004 --------------
> CPCAP_REG_TXI       0x0804 => 0x0004 => 0x0000 => 0x0cc6
> CPCAP_REG_TXMP      0x079c => 0x079c => 0x0400 => 0x0673
> CPCAP_REG_RXOA      0x0000 => 0x0000 => 0x0001 => 0x0001
> CPCAP_REG_RXVC      0x0d34 => 0x0d34 => 0x0000 => 0x0b2c
> CPCAP_REG_RXCOA     0x0000 => 0x0000 => 0x0000 => 0x0601
> CPCAP_REG_RXSDOA    0x0000 => 0x0000 => 0x0600 => 0x0600
> CPCAP_REG_RXEPOA    -------------- 0x0400 --------------
> CPCAP_REG_RXLL      -------------- 0x0000 --------------
> CPCAP_REG_A2LA      -------------- 0x0030 --------------
> CPCAP_REG_MIPIS1    -------------- 0x0000 --------------
> CPCAP_REG_MIPIS2    -------------- 0x0000 --------------
> CPCAP_REG_MIPIS3    -------------- 0x0000 --------------
> CPCAP_REG_LVAB      -------------- 0x0000 --------------

Great thanks! Care to do also a dump just playing music to on
bluetooth headset at some point?

Regards,

Tony

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

Hi,

On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <sre@kernel.org> [200214 13:05]:
> > On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
> > > And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio
> > > above.
> > 
> > My understanding is, that CPU is not involved for calls (except for
> > setting up cpcap registers correctly). Basically McBSP3 should
> > remain idle for a call and data goes directly from modem to cpcap.
> > The same should work for modem <-> BT, except that CPCAP seems to
> > always provide the clock. That would imply a direct link between
> > modem and codec / BT?
> 
> Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during
> voice call though, I guess it should be doable since mcbsp is not
> the clock master :)
> 
> > > 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 can provider register values once I find some time.

[NI] Normal idle (no BT headset connected)
[BI] Bluetooth idle (with BT headset connected)
[BC] Bluetooth call in progress
[NC] Normal call in progress (BT headset disabled)

                     [NI]  =>  [BI]  =>  [BC]  =>  [NC]
CPCAP_REG_VAUDIOC   0x0065 => 0x0065 => 0x0065 => 0x0025
CPCAP_REG_CC        0x0000 => 0x0000 => 0x6000 => 0x60df
CPCAP_REG_CDI       0x0040 => 0x0000 => 0xaa40 => 0xae0a
CPCAP_REG_SDAC      -------------- 0x0000 --------------
CPCAP_REG_SDACDI    -------------- 0x0004 --------------
CPCAP_REG_TXI       0x0804 => 0x0004 => 0x0000 => 0x0cc6
CPCAP_REG_TXMP      0x079c => 0x079c => 0x0400 => 0x0673
CPCAP_REG_RXOA      0x0000 => 0x0000 => 0x0001 => 0x0001
CPCAP_REG_RXVC      0x0d34 => 0x0d34 => 0x0000 => 0x0b2c
CPCAP_REG_RXCOA     0x0000 => 0x0000 => 0x0000 => 0x0601
CPCAP_REG_RXSDOA    0x0000 => 0x0000 => 0x0600 => 0x0600
CPCAP_REG_RXEPOA    -------------- 0x0400 --------------
CPCAP_REG_RXLL      -------------- 0x0000 --------------
CPCAP_REG_A2LA      -------------- 0x0030 --------------
CPCAP_REG_MIPIS1    -------------- 0x0000 --------------
CPCAP_REG_MIPIS2    -------------- 0x0000 --------------
CPCAP_REG_MIPIS3    -------------- 0x0000 --------------
CPCAP_REG_LVAB      -------------- 0x0000 --------------

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

Hi Tony,

On 18/02/2020 1.10, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>> and everything happens betwee the modem and the cpcap pmic.
>>
>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>> or McPDM...
>>
>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
> 
> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
> mcbsp for voice call.
> 
> According to Sebastian sounds like mcbsp can be idle at that point.
> 
> But what about capture of voice call at the mcbsp from the
> TDM slot? In that case mcbsp would be active.

Sure, but with the dummy dai it won't....

If I understand correctly the HW setup:
McBSP2 -> CPCAP_hifi (only playback)

CPCAP_voice is the i2s clock master.
McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
i2s lines.

In case of Voice call with analog mic/speaker only CPCAP_voice and
MDM6600 is used.
In case of Voice call with BT only MDM6600 and WL1285 is used (but
CPCAP_voice must provide the clocks?)
In case you would have any algorithm running on OMAP4 for the calls,
then you will have McBSP3 inserted and used between MDM6600 and
CPAC_voice/WL1285.
Similarly, if you would like to tap in and record the data from the bus
you will have McBSP3 enabled.

The simplest use cases you want to support:
A. McBSP3 <-> CPCAP_voice (playback/capture)
B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
C. MDM6600 <-> WL1285 (BT voice call)
D. McBSP3 <-> BT (VoIP?)

I would not bother with recording the call as you would need tom
reconfigure the McBSP playback pin (is it even possible) as input to
OMAP4, I think..

B/C is codec2codec, McBSP3 is not involved at all.
A/D is when McBSP3 is used only.

Imho this can be represented as
McBSP2: 1 port
	1.1: to CPCAP_hifi

McBSP3: 1 port, 2 endpoint
	2.1: to CPCAP_voice
	2.2: to WL1285
CPCAP: 2 ports
	hifi:	3.1: to McBSP2
	voice:	4.1: to McBSP3
		4.2: to MDM6600
MDM6600: 2 ports
	5.1: to CPAC_voice
	5.2: to WL1285
WL1285: 2 ports
	6.1: to McBSP3
	6.2: to MDM6600

The machine driver should switch between the graph links based on the
use case for the interconnected devices:
A: 2.2 <-> 4.1
B: 4.2 <-> 5.1
C: 6.2 <-> 5.1
D: 2.2 <-> 6.1

Can a generic card provide such a functionality?
In case of B/C you should not have a running stream imho.
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?

I'm not sure if we should span out dummy dais for endpoints within a
port. Imho the port _is_ the dai. Different endpoints might use
different TDM slots on the port (or the same slot, which makes them
exclusive).

> 
>>>>>> I know it was discussed, but can not find the mail:
>>>>>> Can you brief again on the audio connection?
>>>>>
>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>> the audio connection:
>>>>>
>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>
>>>> Thanks!
>>>>  
>>>>>> Do you have branch with working code?
>>>>>
>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>> kernel.org git branch with voice calls working.
>>>>
>>>> I think I should put my droid4 out and try to get it working...
>>>> Do you have a link for dummies to follow to get started? ;)
>>>
>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>> test image using v5.5 kernel + modem and audio patches:
>>>
>>> https://leste.maemo.org/Motorola_Droid_4
>>>
>>> Just use a decent speed micro-sd card rated "a1" for example.
>>
>> Cool. Now I can dual boot the droid4 :D
>> I needed to rewrite the /etc/shadow to get a known root password so I
>> can log in.
> 
> Not sure if you mean password for the droid4-kexecboot or the
> Linux distro you installed..

It was for the maemo-leste.
Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
reference image...

> But for droid4-kexecboot, you
> can configure it to automatically download new kernels over wlan.
> There's some info on the machine specific password and how to
> configure wlan in the droid4-kexecboot buildroot commits here:
> 
> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
> 
>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>> the /boot/boot/boot.cfg to boot my kernel, right?
> 
> Yeah you can update kernels and modules over wlan from the distro(s)
> you have configured, and also from droid4-kexecboot as above.

I need to try droid4-kexecboot's wifi support then.

> And note that kexecboot looks for a boot/boot.cfg file to use on
> every usable parition it finds and uses all the found entries
> based on the priority configured for the boot.cfg entry.

OK, thanks!

> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [200217 23:10]:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
> > On 14/02/2020 19.03, Tony Lindgren wrote:
> > > But right now in droid4 voice call case mcbsp is just the i2s transport,
> > > and everything happens betwee the modem and the cpcap pmic.
> > 
> > Iow you don't need McBSP DAI at all. If you would have added the dummy
> > codec to McBSP !3 and use that, it would work in a same way, or to DMIC
> > or McPDM...
> > 
> > The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
> 
> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
> mcbsp for voice call.
> 
> According to Sebastian sounds like mcbsp can be idle at that point.
> 
> But what about capture of voice call at the mcbsp from the
> TDM slot? In that case mcbsp would be active.

Looks like only initializing only one mcbsp3 instance here
instead of two will produce an oops as below.

I'm not sure how this is supposed to work for
snd-soc-audio-graph-card with multipe endpoints connected
to just one mcbsp dai instance?

Regards,

Tony

8< -------------------
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
snd_soc_del_component_unlocked+0xf4/0x110
...
[   39.616027] Backtrace:
[   39.616149] [<bf3f6bc4>] (snd_soc_del_component_unlocked [snd_soc_core]) from [<bf3f8ff4>] (snd_soc_add_component+0x238/0x374 [snd_s)
[   39.616149]  r7:00000002 r6:00000002 r5:ec9a0e78 r4:00000122
[   39.678283] qmi_wwan 1-1:1.6: cdc-wdm1: USB WDM device
[   39.739074] [<bf3f8dbc>] (snd_soc_add_component [snd_soc_core]) from [<bf3f9180>] (snd_soc_register_component+0x50/0x60 [snd_soc_cor)
[   39.739074]  r10:bf4582d0 r9:ec9d0840 r8:00000002 r7:00000002 r6:ec9d0640 r5:bf4584ac
[   39.800842] asoc-audio-graph-card soundcard: using device tree for GPIO lookup
[   39.808685]  r4:eed52410
[   39.862304] [<bf3f9130>] (snd_soc_register_component [snd_soc_core]) from [<bf4088b4>] (devm_snd_soc_register_component+0x54/0x90 [s)
[   39.862304]  r7:ec9d0640 r6:bf4584ac r5:ec9d3040 r4:eed52410
[   39.925048] qmi_wwan 1-1:1.6 wwan1: register 'qmi_wwan' at usb-4a064800.ohci-1, WWAN/QMI device, 2e:59:df:3f:4f:ef
[   39.984558] [<bf408860>] (devm_snd_soc_register_component [snd_soc_core]) from [<bf456fb8>] (asoc_mcbsp_probe+0x3e8/0x574 [snd_soc_o)
[   39.984558]  r9:ec9d0840 r8:ec9f4000 r7:eed52410 r6:00000000 r5:eed52400 r4:ec9d0840
[   39.984588] [<bf456bd0>] (asoc_mcbsp_probe [snd_soc_omap_mcbsp]) from [<c068475c>] (platform_drv_probe+0x58/0xa8)
[   39.984619]  r10:00000000 r9:0000002e r8:bf459014 r7:00000000 r6:bf459014 r5:00000000
[   40.044342] of_get_named_gpiod_flags: can't parse 'pa-gpios' property of node '/soundcard[0]'
[   40.051788]  r4:eed52410
[   40.100769] [<c0684704>] (platform_drv_probe) from [<c06820ac>] (really_probe+0x1ec/0x358)

Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
> On 14/02/2020 19.03, Tony Lindgren wrote:
> > But right now in droid4 voice call case mcbsp is just the i2s transport,
> > and everything happens betwee the modem and the cpcap pmic.
> 
> Iow you don't need McBSP DAI at all. If you would have added the dummy
> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
> or McPDM...
> 
> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.

Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
mcbsp for voice call.

According to Sebastian sounds like mcbsp can be idle at that point.

But what about capture of voice call at the mcbsp from the
TDM slot? In that case mcbsp would be active.

> >>>> I know it was discussed, but can not find the mail:
> >>>> Can you brief again on the audio connection?
> >>>
> >>> Below is a link to a mailing list thread where Sebastian describes
> >>> the audio connection:
> >>>
> >>> https://lkml.org/lkml/2018/3/28/881
> >>
> >> Thanks!
> >>  
> >>>> Do you have branch with working code?
> >>>
> >>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
> >>> kernel.org git branch with voice calls working.
> >>
> >> I think I should put my droid4 out and try to get it working...
> >> Do you have a link for dummies to follow to get started? ;)
> > 
> > Probably the easiest one to use right now is the Maemo-leste devuan based
> > test image using v5.5 kernel + modem and audio patches:
> > 
> > https://leste.maemo.org/Motorola_Droid_4
> > 
> > Just use a decent speed micro-sd card rated "a1" for example.
> 
> Cool. Now I can dual boot the droid4 :D
> I needed to rewrite the /etc/shadow to get a known root password so I
> can log in.

Not sure if you mean password for the droid4-kexecboot or the
Linux distro you installed.. But for droid4-kexecboot, you
can configure it to automatically download new kernels over wlan.
There's some info on the machine specific password and how to
configure wlan in the droid4-kexecboot buildroot commits here:

https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11

> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
> the /boot/boot/boot.cfg to boot my kernel, right?

Yeah you can update kernels and modules over wlan from the distro(s)
you have configured, and also from droid4-kexecboot as above.

And note that kexecboot looks for a boot/boot.cfg file to use on
every usable parition it finds and uses all the found entries
based on the priority configured for the boot.cfg entry.

Regards,

Tony