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

Commit Message

Tony Lindgren Feb. 11, 2020, 5:16 p.m. UTC

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 <[e-mail]>
Cc: Arthur D. <[e-mail]>
Cc: Jarkko Nikula <[e-mail]>
Cc: Merlijn Wajer <[e-mail]>
Cc: Pavel Machek <[e-mail]>
Cc: Peter Ujfalusi <[e-mail]>
Cc: Sebastian Reichel <[e-mail]>
Signed-off-by: Tony Lindgren <[e-mail]>
---
 sound/soc/ti/omap-mcbsp-priv.h |  2 +
 sound/soc/ti/omap-mcbsp.c      | 76 ++++++++++++++++++++++++----------
 2 files changed, 55 insertions(+), 23 deletions(-)

Comments

Peter Ujfalusi Feb. 12, 2020, 8:02 a.m. UTC | #1

On 11/02/2020 19.16, Tony Lindgren wrote:
> 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.

It is still one DAI...
If you have multiple codec connected to the same I2S lines, but the
codecs communicate within different time slots, you still have one DAI
on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.

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

See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
The PCM3168a have 2 DAIs: playback and capture, but you can have
multiple endpoints within a DAI.

> 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.
You also rename the DAIs, which might break ams-delta.

We still have legacy support in
omap-twl4030.c
omap3pandora.c
osk5912.c
rx51.c

which will break with the renamed DAI. On the other hand I think the
legacy support can be dropped from them.

I know it was discussed, but can not find the mail:
Can you brief again on the audio connection?
Do you have branch with working code?

- Péter

> Cc: Aaro Koskinen <[e-mail]>
> Cc: Arthur D. <[e-mail]>
> Cc: Jarkko Nikula <[e-mail]>
> Cc: Merlijn Wajer <[e-mail]>
> Cc: Pavel Machek <[e-mail]>
> Cc: Peter Ujfalusi <[e-mail]>
> Cc: Sebastian Reichel <[e-mail]>
> Signed-off-by: Tony Lindgren <[e-mail]>
> ---
>  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
> --- 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
> --- 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>
> @@ -1304,23 +1305,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",
> @@ -1409,18 +1440,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;
>  
> 

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

Tony Lindgren Feb. 12, 2020, 2:35 p.m. UTC | #2

* Peter Ujfalusi <[e-mail]> [200212 08:02]:
> 
> 
> On 11/02/2020 19.16, Tony Lindgren wrote:
> > 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.
> 
> It is still one DAI...
> If you have multiple codec connected to the same I2S lines, but the
> codecs communicate within different time slots, you still have one DAI
> on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.

OK so subject should say "dodec DAIs" then I guess?

> > See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
> > Documentation/devicetree/bindings/graph.txt for more details for
> > multiple endpoints.
> 
> See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
> The PCM3168a have 2 DAIs: playback and capture, but you can have
> multiple endpoints within a DAI.

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 {
                                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 {
                                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'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
> 
> 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.

> 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

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

Regards,

Tony

Sebastian Reichel Feb. 14, 2020, 12:34 a.m. UTC | #3

Hi,

On Wed, Feb 12, 2020 at 06:35:43AM -0800, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [200212 08:02]:
> > On 11/02/2020 19.16, Tony Lindgren wrote:
> > > 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.
> > 
> > It is still one DAI...
> > If you have multiple codec connected to the same I2S lines, but the
> > codecs communicate within different time slots, you still have one DAI
> > on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.
> 
> OK so subject should say "dodec DAIs" then I guess?
> 
> > > See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
> > > Documentation/devicetree/bindings/graph.txt for more details for
> > > multiple endpoints.
> > 
> > See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
> > The PCM3168a have 2 DAIs: playback and capture, but you can have
> > multiple endpoints within a DAI.
> 
> 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

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

&mcbsp3 {
    ports {
        port@0 {
            cpu_dai3_cpcap: endpoint@0 {};
            cpu_dai3_modem: endpoint@1 {};
            cpu_dai3_bt: endpoint@2 {};
        };
    };
};

&cpcap {
    ports {
        voice: port@1 {
            cpcap_voice_cpu: endpoint@0 {};
            cpcap_voice_modem: endpoint@1 {};
            cpcap_voice_bt: endpoint@2 {};
        };
    };
};

&modem {
    ports {
        port@0 {
            modem_voice_cpu: endpoint@0 {};
            modem_voice_cpcap: endpoint@1 {};
            modem_voice_bt: endpoint@2 {};
        };
    };
};

&bluetooth {
    ports {
        port@0 {
            bt_dai_cpu: endpoint@0 {};
            bt_dai_modem: endpoint@1 {};
            bt_dai_cpcap: endpoint@2 {};
        };
    };
};

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

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

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

-- Sebastian

Tony Lindgren Feb. 14, 2020, 1:34 a.m. UTC | #4

* Sebastian Reichel <[e-mail]> [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

Peter Ujfalusi Feb. 14, 2020, 12:41 p.m. UTC | #5

Hi Tony,

On 12/02/2020 16.35, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [200212 08:02]:
>>
>>
>> On 11/02/2020 19.16, Tony Lindgren wrote:
>>> 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.
>>
>> It is still one DAI...
>> If you have multiple codec connected to the same I2S lines, but the
>> codecs communicate within different time slots, you still have one DAI
>> on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.
> 
> OK so subject should say "dodec DAIs" then I guess?
> 
>>> See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
>>> Documentation/devicetree/bindings/graph.txt for more details for
>>> multiple endpoints.
>>
>> See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
>> The PCM3168a have 2 DAIs: playback and capture, but you can have
>> multiple endpoints within a DAI.
> 
> 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 {
>                                 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 {
>                                 reg = <1>;
>                                 dai-format = "dsp_a";
>                                 frame-master = <&cpcap_audio_codec1>;
>                                 bitclock-master = <&cpcap_audio_codec1>;
>                                 remote-endpoint = <&mot_mdm6600_audio_codec0>;
>                         };
>                 };
>         };
> };

According to
Documentation/devicetree/bindings/sound/audio-graph-card.txt
it should be something like this:
&mcbsp3 {
        #sound-dai-cells = <0>;
        pinctrl-names = "default";
        pinctrl-0 = <&mcbsp3_pins>;
        status = "okay";

        ports {
		#address-cells = <1>;
		#size-cells = <0>;
                port@0 {
			reg = <0>;

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

If you span out dummy DAIs got dai1+ then how you will get anything
working via endpoint1+?
There will be no ops for McBSP, so it is not going to do anything...


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

The audio-graph-card.txt example shows pcm3168a which have two DAIs,
one for playback and one for capture.

I guess Morimoto-san can explain if he carries out of tree patches to
get the described setup working on top of mainline...

But, no, based on the documentation I don't ;)

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

That's an option, yes, if we really need extra dummy McBSP DAIs at all,
again, let's hear from Morimoto-san or Mark.
 
>> We still have legacy support in
>> omap-twl4030.c
>> omap3pandora.c
>> osk5912.c
>> rx51.c
>>
>> 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.

For some it should not be a big deal as they only boot in DT mode.
/me adds this to the TODO list.
 
>> 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? ;)

> 
> Regards,
> 
> Tony
> 

- Péter

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

Mark Brown Feb. 14, 2020, 12:49 p.m. UTC | #6

On Fri, Feb 14, 2020 at 02:41:30PM +0200, Peter Ujfalusi wrote:
> On 12/02/2020 16.35, Tony Lindgren wrote:

> > Oops, that's not good. So should we just keep the old naming if there's
> > only one endpoint?

> That's an option, yes, if we really need extra dummy McBSP DAIs at all,
> again, let's hear from Morimoto-san or Mark.

We really shouldn't need dummy DAIs at all I think, if we do it feels
like there's a problem.  It's quite possible that there is actually a
problem here though...

Sebastian Reichel Feb. 14, 2020, 1:04 p.m. UTC | #7

Hi,

On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <[e-mail]> [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.
> 
[...]
>
> 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 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?

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

-- Sebastian

Tony Lindgren Feb. 14, 2020, 5:03 p.m. UTC | #8

* Peter Ujfalusi <[e-mail]> [200214 12:42]:
> Hi Tony,
> 
> On 12/02/2020 16.35, Tony Lindgren wrote:
> > * Peter Ujfalusi <[e-mail]> [200212 08:02]:
> >>
> >>
> >> On 11/02/2020 19.16, Tony Lindgren wrote:
> >>> 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.
> >>
> >> It is still one DAI...
> >> If you have multiple codec connected to the same I2S lines, but the
> >> codecs communicate within different time slots, you still have one DAI
> >> on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.
> > 
> > OK so subject should say "dodec DAIs" then I guess?
> > 
> >>> See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
> >>> Documentation/devicetree/bindings/graph.txt for more details for
> >>> multiple endpoints.
> >>
> >> See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
> >> The PCM3168a have 2 DAIs: playback and capture, but you can have
> >> multiple endpoints within a DAI.
> > 
> > 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 {
> >                                 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 {
> >                                 reg = <1>;
> >                                 dai-format = "dsp_a";
> >                                 frame-master = <&cpcap_audio_codec1>;
> >                                 bitclock-master = <&cpcap_audio_codec1>;
> >                                 remote-endpoint = <&mot_mdm6600_audio_codec0>;
> >                         };
> >                 };
> >         };
> > };
> 
> According to
> Documentation/devicetree/bindings/sound/audio-graph-card.txt
> it should be something like this:
> &mcbsp3 {
>         #sound-dai-cells = <0>;
>         pinctrl-names = "default";
>         pinctrl-0 = <&mcbsp3_pins>;
>         status = "okay";
> 
>         ports {
> 		#address-cells = <1>;
> 		#size-cells = <0>;
>                 port@0 {
> 			reg = <0>;
> 
> 			cpu_dai3: endpoint@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 {
> 				dai-format = "dsp_a";
> 				frame-master = <&cpcap_audio_codec1>;
> 				bitclock-master = <&cpcap_audio_codec1>;
> 				remote-endpoint = <&mot_mdm6600_audio_codec0>;
> 			};
> 		};
> 	};
> };

Hmms so I only spot reg use at different level changing above. Well
that's not according to Documentation/devicetree/bindings/graph.txt,
the reg numbering is per endpoint.

Sounds like the we have the example not following graph.txt in
Documentation/devicetree/bindings/sound/audio-graph-card.txt while
the code is now behaving as in graph.txt.

> If you span out dummy DAIs got dai1+ then how you will get anything
> working via endpoint1+?
> There will be no ops for McBSP, so it is not going to do anything...

Eventually it could have ops though. For things like capture of the tdm
slot data for recording audio call for example, I don't know how that's
supposed to work though. I guess mcbsp could be the clock master too,
and for those cases it would have ops.

But right now in droid4 voice call case mcbsp is just the i2s transport,
and everything happens betwee the modem and the cpcap pmic.

> > 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?
> 
> The audio-graph-card.txt example shows pcm3168a which have two DAIs,
> one for playback and one for capture.
> 
> I guess Morimoto-san can explain if he carries out of tree patches to
> get the described setup working on top of mainline...
>
> But, no, based on the documentation I don't ;)

Sounds like audio-graph-card.txt is just out of sync with graph.txt
as we do have several working examples?

> >>> 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?
> 
> That's an option, yes, if we really need extra dummy McBSP DAIs at all,
> again, let's hear from Morimoto-san or Mark.

Well it would not necessarily be a dummy mcbsp dai in all cases it seems
to me. But yeah nothing for the second dai to do right now for droid4
voice call as it's all between the modem and the pmic.

> >> We still have legacy support in
> >> omap-twl4030.c
> >> omap3pandora.c
> >> osk5912.c
> >> rx51.c
> >>
> >> 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.
> 
> For some it should not be a big deal as they only boot in DT mode.
> /me adds this to the TODO list.

OK

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

Regards,

Tony

Tony Lindgren Feb. 14, 2020, 5:05 p.m. UTC | #9

* Mark Brown <[e-mail]> [200214 12:50]:
> On Fri, Feb 14, 2020 at 02:41:30PM +0200, Peter Ujfalusi wrote:
> > On 12/02/2020 16.35, Tony Lindgren wrote:
> 
> > > Oops, that's not good. So should we just keep the old naming if there's
> > > only one endpoint?
> 
> > That's an option, yes, if we really need extra dummy McBSP DAIs at all,
> > again, let's hear from Morimoto-san or Mark.
> 
> We really shouldn't need dummy DAIs at all I think, if we do it feels
> like there's a problem.  It's quite possible that there is actually a
> problem here though...

It's dummy in the droid4 voice call case as mcbsp is not the clock-master
and there's nothing to configure for mcbsp.

But I guess in some cases mcbsp could be the clock-master and then the
secondary DAI would have ops.

I could be wrong though, this is just based on my experience with
getting one device working.

Regards,

Tony

Tony Lindgren Feb. 14, 2020, 5:09 p.m. UTC | #10

* Sebastian Reichel <[e-mail]> [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.

OK great.

Regards,

Tony

Mark Brown Feb. 14, 2020, 8:05 p.m. UTC | #11

On Fri, Feb 14, 2020 at 09:05:59AM -0800, Tony Lindgren wrote:
> * Mark Brown <[e-mail]> [200214 12:50]:

> > We really shouldn't need dummy DAIs at all I think, if we do it feels
> > like there's a problem.  It's quite possible that there is actually a
> > problem here though...

> It's dummy in the droid4 voice call case as mcbsp is not the clock-master
> and there's nothing to configure for mcbsp.

If the McBSP is doing anything at all it should still be properly
represented with the actual device rather than a dummy otherwise we'll
most likely get confused at some point.  If it's not doing anything then
we shouldn't even need the dummy.  But perhaps I'm confused about this
particular system, I remember some of the OMAP designs were a bit fun.

> But I guess in some cases mcbsp could be the clock-master and then the
> secondary DAI would have ops.

It'd be a bit of an unusual clock design for a phone but yeah.

Kuninori Morimoto Feb. 17, 2020, 1:38 a.m. UTC | #12

Hi

> > According to
> > Documentation/devicetree/bindings/sound/audio-graph-card.txt
> > it should be something like this:
> > &mcbsp3 {
> >         #sound-dai-cells = <0>;
> >         pinctrl-names = "default";
> >         pinctrl-0 = <&mcbsp3_pins>;
> >         status = "okay";
> > 
> >         ports {
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> >                 port@0 {
> > 			reg = <0>;
> > 
> > 			cpu_dai3: endpoint@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 {
> > 				dai-format = "dsp_a";
> > 				frame-master = <&cpcap_audio_codec1>;
> > 				bitclock-master = <&cpcap_audio_codec1>;
> > 				remote-endpoint = <&mot_mdm6600_audio_codec0>;
> > 			};
> > 		};
> > 	};
> > };
(snip)
> > I guess Morimoto-san can explain if he carries out of tree patches to
> > get the described setup working on top of mainline...

# I think ALSA ML is rejecting mail (?),
# I couldn't find original patch / Mail and Discussion at ALSA ML.
# Thus, I'm not 100% understanding what is the issue...

I confirmed attached patch on my local platform (= Renesas ULCB + KF board),
and it works well for me on at least v5.5 kernel.

--- kernel log --------------
...
[    2.184193] rcar_sound ec500000.sound: probed
...
[    2.227837] asoc-audio-graph-card sound: ak4613-hifi <-> rsnd-dai.0 mapping ok
[    2.235474] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.2 mapping ok
[    2.243472] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.3 mapping ok
[    2.251463] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.4 mapping ok
[    2.259451] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.5 mapping ok
[    2.267448] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.6 mapping ok
[    2.275439] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.7 mapping ok
[    2.283429] asoc-audio-graph-card sound: snd-soc-dummy-dai <-> rsnd-dai.8 mapping ok
[    2.291460] asoc-audio-graph-card sound: pcm3168a-dac <-> snd-soc-dummy-dai mapping ok
[    2.299460] asoc-audio-graph-card sound: pcm3168a-adc <-> snd-soc-dummy-dai mapping ok
...
[    5.479675] ALSA device list:
[    5.482694]   #0: rcar-sound
...

--- local patch -------------------

From 8d25a2ce640ec5be506584ab50e685d0a962aa2d Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <[e-mail]>
Date: Fri, 14 Dec 2018 09:47:47 +0900
Subject: [PATCH] Local v5.4: ulcb-kf: add TDM Split support

	CPU0 ------ ak4613
	CPU1 ------ PCM3168A-p	/* 1ch/2ch */
	CPU2 --/		/* 3ch/4ch */
	CPU3 --/		/* 5ch/6ch */
	CPU4 --/		/* 7ch/8ch */
	CPU5 ------ PCM3168A-c	/* 1ch/2ch */
	CPU6 --/		/* 3ch/4ch */
	CPU7 --/		/* 5ch/6ch */

aplay   -D plughw:0,0 xxx.wav // ak4613
aplay   -D plughw:0,1 xxx.wav // PCM3168A playback 1ch/2ch
aplay   -D plughw:0,2 xxx.wav // PCM3168A playback 3ch/4ch
aplay   -D plughw:0,3 xxx.wav // PCM3168A playback 5ch/6ch
aplay   -D plughw:0,4 xxx.wav // PCM3168A playback 7ch/8ch
arecord -D plughw:0,5 xxx     // PCM8168A capture  1ch/2ch
arecord -D plughw:0,6 xxx     // PCM8168A capture  3ch/4ch
arecord -D plughw:0,7 xxx     // PCM8168A capture  5ch/6ch

It seems 1 sound card DAI number is limited by SNDRV_MINOR().
Because of this size limit, total 8 DAI seems maximam.
So, this patch removes HDMI so far.

Signed-off-by: Kuninori Morimoto <[e-mail]>
---
 arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 103 +++++++++++++++++++++--
 1 file changed, 94 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 202177706cde..5eaf97ea7480 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -115,18 +115,39 @@
 					#size-cells = <0>;
 					mclk-fs = <512>;
 					port@0 {
+						prefix = "pcm3168a";
+						convert-channels = <8>; /* TDM Split */
 						reg = <0>;
-						pcm3168a_endpoint_p: endpoint {
+						pcm3168a_endpoint_p: endpoint@0 {
 							remote-endpoint = <&rsnd_for_pcm3168a_play>;
 							clocks = <&clksndsel>;
 						};
+						pcm3168a_endpoint_p2: endpoint@1 {
+							remote-endpoint = <&rsnd_for_pcm3168a_play2>;
+						};
+						pcm3168a_endpoint_p3: endpoint@2 {
+							remote-endpoint = <&rsnd_for_pcm3168a_play3>;
+						};
+						pcm3168a_endpoint_p4: endpoint@3 {
+							remote-endpoint = <&rsnd_for_pcm3168a_play4>;
+						};
 					};
 					port@1 {
+						prefix = "pcm3168a";
+						convert-channels = <6>; /* TDM Split */
 						reg = <1>;
-						pcm3168a_endpoint_c: endpoint {
+						pcm3168a_endpoint_c: endpoint@0 {
 							remote-endpoint = <&rsnd_for_pcm3168a_capture>;
 							clocks = <&clksndsel>;
 						};
+						pcm3168a_endpoint_c2: endpoint@1 {
+							remote-endpoint = <&rsnd_for_pcm3168a_capture2>;
+							clocks = <&clksndsel>;
+						};
+						pcm3168a_endpoint_c3: endpoint@2 {
+							remote-endpoint = <&rsnd_for_pcm3168a_capture3>;
+							clocks = <&clksndsel>;
+						};
 					};
 				};
 			};
@@ -298,29 +319,83 @@
 	ports {
 		/* rsnd_port0/1 are on salvator-common */
 		rsnd_port2: port@2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
 			reg = <2>;
-			rsnd_for_pcm3168a_play: endpoint {
+			rsnd_for_pcm3168a_play: endpoint@2 {
+				reg = <2>;
 				remote-endpoint = <&pcm3168a_endpoint_p>;
 
 				dai-format = "i2s";
 				bitclock-master = <&rsnd_for_pcm3168a_play>;
 				frame-master = <&rsnd_for_pcm3168a_play>;
-				dai-tdm-slot-num = <8>;
 
-				playback = <&ssi3>;
+				playback = <&ssiu30 &ssi3>;
+			};
+			rsnd_for_pcm3168a_play2: endpoint@3 {
+				reg = <3>;
+				remote-endpoint = <&pcm3168a_endpoint_p2>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_play2>;
+				frame-master = <&rsnd_for_pcm3168a_play2>;
+
+				playback = <&ssiu31 &ssi3>;
+			};
+			rsnd_for_pcm3168a_play3: endpoint@4 {
+				reg = <4>;
+				remote-endpoint = <&pcm3168a_endpoint_p3>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_play3>;
+				frame-master = <&rsnd_for_pcm3168a_play3>;
+
+				playback = <&ssiu32 &ssi3>;
+			};
+			rsnd_for_pcm3168a_play4: endpoint@5 {
+				reg = <5>;
+				remote-endpoint = <&pcm3168a_endpoint_p4>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_play4>;
+				frame-master = <&rsnd_for_pcm3168a_play4>;
+
+				playback = <&ssiu33 &ssi3>;
 			};
 		};
 		rsnd_port3: port@3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
 			reg = <3>;
-			rsnd_for_pcm3168a_capture: endpoint {
+			rsnd_for_pcm3168a_capture: endpoint@6 {
+				reg = <6>;
 				remote-endpoint = <&pcm3168a_endpoint_c>;
 
 				dai-format = "i2s";
 				bitclock-master = <&rsnd_for_pcm3168a_capture>;
 				frame-master = <&rsnd_for_pcm3168a_capture>;
-				dai-tdm-slot-num = <6>;
 
-				capture  = <&ssi4>;
+				capture  = <&ssiu40 &ssi4>;
+			};
+			rsnd_for_pcm3168a_capture2: endpoint@7 {
+				reg = <7>;
+				remote-endpoint = <&pcm3168a_endpoint_c2>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_capture2>;
+				frame-master = <&rsnd_for_pcm3168a_capture2>;
+
+				capture  = <&ssiu41 &ssi4>;
+			};
+			rsnd_for_pcm3168a_capture3: endpoint@8 {
+				reg = <8>;
+				remote-endpoint = <&pcm3168a_endpoint_c3>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_capture3>;
+				frame-master = <&rsnd_for_pcm3168a_capture3>;
+
+				capture  = <&ssiu42 &ssi4>;
 			};
 		};
 	};
@@ -359,8 +434,18 @@
 };
 
 &sound_card {
+	compatible = "audio-graph-scu-card";
+
+	routing =	"pcm3168a Playback", "DAI2 Playback",
+			"pcm3168a Playback", "DAI3 Playback",
+			"pcm3168a Playback", "DAI4 Playback",
+			"pcm3168a Playback", "DAI5 Playback",
+			"DAI6 Capture", "pcm3168a Capture",
+			"DAI7 Capture", "pcm3168a Capture",
+			"DAI8 Capture", "pcm3168a Capture";
+
 	dais = <&rsnd_port0	/* ak4613 */
-		&rsnd_port1	/* HDMI0  */
+//		&rsnd_port1	/* HDMI0  */
 		&rsnd_port2	/* pcm3168a playback */
 		&rsnd_port3	/* pcm3168a capture  */
 		>;

Kuninori Morimoto Feb. 17, 2020, 5:25 a.m. UTC | #13

Hi

> I confirmed attached patch on my local platform (= Renesas ULCB + KF board),
> and it works well for me on at least v5.5 kernel.

Maybe my DT patch was not good for port vs endpoint.
I attached new one.

--------------------------
From a222375f826f650d1181646cc79b8b89b364da2a Mon Sep 17 00:00:00 2001
From: Kuninori Morimoto <[e-mail]>
Date: Fri, 14 Dec 2018 09:47:47 +0900
Subject: [PATCH 1/2] Local v5.4: ulcb-kf: add TDM Split support

	CPU0 ------ ak4613
	CPU1 ------ PCM3168A-p	/* 1ch/2ch */
	CPU2 --/		/* 3ch/4ch */
	CPU3 --/		/* 5ch/6ch */
	CPU4 --/		/* 7ch/8ch */
	CPU5 ------ PCM3168A-c	/* 1ch/2ch */
	CPU6 --/		/* 3ch/4ch */
	CPU7 --/		/* 5ch/6ch */

aplay   -D plughw:0,0 xxx.wav // ak4613
aplay   -D plughw:0,1 xxx.wav // PCM3168A playback 1ch/2ch
aplay   -D plughw:0,2 xxx.wav // PCM3168A playback 3ch/4ch
aplay   -D plughw:0,3 xxx.wav // PCM3168A playback 5ch/6ch
aplay   -D plughw:0,4 xxx.wav // PCM3168A playback 7ch/8ch
arecord -D plughw:0,5 xxx     // PCM8168A capture  1ch/2ch
arecord -D plughw:0,6 xxx     // PCM8168A capture  3ch/4ch
arecord -D plughw:0,7 xxx     // PCM8168A capture  5ch/6ch

It seems 1 sound card DAI number is limited by SNDRV_MINOR().
Because of this size limit, total 8 DAI seems maximam.
So, this patch removes HDMI so far.

Signed-off-by: Kuninori Morimoto <[e-mail]>
---
 arch/arm64/boot/dts/renesas/ulcb-kf.dtsi | 116 ++++++++++++++++++++---
 1 file changed, 105 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 202177706cde..2c3bd62d13ff 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -115,18 +115,39 @@
 					#size-cells = <0>;
 					mclk-fs = <512>;
 					port@0 {
+						prefix = "pcm3168a";
+						convert-channels = <8>; /* TDM Split */
 						reg = <0>;
-						pcm3168a_endpoint_p: endpoint {
+						pcm3168a_endpoint_p: endpoint@0 {
 							remote-endpoint = <&rsnd_for_pcm3168a_play>;
 							clocks = <&clksndsel>;
 						};
+						pcm3168a_endpoint_p2: endpoint@1 {
+							remote-endpoint = <&rsnd_for_pcm3168a_play2>;
+						};
+						pcm3168a_endpoint_p3: endpoint@2 {
+							remote-endpoint = <&rsnd_for_pcm3168a_play3>;
+						};
+						pcm3168a_endpoint_p4: endpoint@3 {
+							remote-endpoint = <&rsnd_for_pcm3168a_play4>;
+						};
 					};
 					port@1 {
+						prefix = "pcm3168a";
+						convert-channels = <6>; /* TDM Split */
 						reg = <1>;
-						pcm3168a_endpoint_c: endpoint {
+						pcm3168a_endpoint_c: endpoint@0 {
 							remote-endpoint = <&rsnd_for_pcm3168a_capture>;
 							clocks = <&clksndsel>;
 						};
+						pcm3168a_endpoint_c2: endpoint@1 {
+							remote-endpoint = <&rsnd_for_pcm3168a_capture2>;
+							clocks = <&clksndsel>;
+						};
+						pcm3168a_endpoint_c3: endpoint@2 {
+							remote-endpoint = <&rsnd_for_pcm3168a_capture3>;
+							clocks = <&clksndsel>;
+						};
 					};
 				};
 			};
@@ -299,28 +320,86 @@
 		/* rsnd_port0/1 are on salvator-common */
 		rsnd_port2: port@2 {
 			reg = <2>;
-			rsnd_for_pcm3168a_play: endpoint {
+			rsnd_for_pcm3168a_play: endpoint@2 {
 				remote-endpoint = <&pcm3168a_endpoint_p>;
 
 				dai-format = "i2s";
 				bitclock-master = <&rsnd_for_pcm3168a_play>;
 				frame-master = <&rsnd_for_pcm3168a_play>;
-				dai-tdm-slot-num = <8>;
 
-				playback = <&ssi3>;
+				playback = <&ssiu30 &ssi3>;
 			};
 		};
 		rsnd_port3: port@3 {
 			reg = <3>;
-			rsnd_for_pcm3168a_capture: endpoint {
+			rsnd_for_pcm3168a_play2: endpoint@3 {
+				remote-endpoint = <&pcm3168a_endpoint_p2>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_play2>;
+				frame-master = <&rsnd_for_pcm3168a_play2>;
+
+				playback = <&ssiu31 &ssi3>;
+			};
+		};
+		rsnd_port4: port@4 {
+			reg = <4>;
+			rsnd_for_pcm3168a_play3: endpoint@4 {
+				remote-endpoint = <&pcm3168a_endpoint_p3>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_play3>;
+				frame-master = <&rsnd_for_pcm3168a_play3>;
+
+				playback = <&ssiu32 &ssi3>;
+			};
+		};
+		rsnd_port5: port@5 {
+			reg = <5>;
+			rsnd_for_pcm3168a_play4: endpoint@5 {
+				remote-endpoint = <&pcm3168a_endpoint_p4>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_play4>;
+				frame-master = <&rsnd_for_pcm3168a_play4>;
+
+				playback = <&ssiu33 &ssi3>;
+			};
+		};
+		rsnd_port6: port@6 {
+			reg = <6>;
+			rsnd_for_pcm3168a_capture: endpoint@6 {
 				remote-endpoint = <&pcm3168a_endpoint_c>;
 
 				dai-format = "i2s";
 				bitclock-master = <&rsnd_for_pcm3168a_capture>;
 				frame-master = <&rsnd_for_pcm3168a_capture>;
-				dai-tdm-slot-num = <6>;
 
-				capture  = <&ssi4>;
+				capture  = <&ssiu40 &ssi4>;
+			};
+		};
+		rsnd_port7: port@7 {
+			reg = <7>;
+			rsnd_for_pcm3168a_capture2: endpoint@7 {
+				remote-endpoint = <&pcm3168a_endpoint_c2>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_capture2>;
+				frame-master = <&rsnd_for_pcm3168a_capture2>;
+
+				capture  = <&ssiu41 &ssi4>;
+			};
+		};
+		rsnd_port8: port@8 {
+			reg = <8>;
+			rsnd_for_pcm3168a_capture3: endpoint@8 {
+				remote-endpoint = <&pcm3168a_endpoint_c3>;
+
+				dai-format = "i2s";
+				bitclock-master = <&rsnd_for_pcm3168a_capture3>;
+				frame-master = <&rsnd_for_pcm3168a_capture3>;
+
+				capture  = <&ssiu42 &ssi4>;
 			};
 		};
 	};
@@ -359,10 +438,25 @@
 };
 
 &sound_card {
+	compatible = "audio-graph-scu-card";
+
+	routing =	"pcm3168a Playback", "DAI2 Playback",
+			"pcm3168a Playback", "DAI3 Playback",
+			"pcm3168a Playback", "DAI4 Playback",
+			"pcm3168a Playback", "DAI5 Playback",
+			"DAI6 Capture", "pcm3168a Capture",
+			"DAI7 Capture", "pcm3168a Capture",
+			"DAI8 Capture", "pcm3168a Capture";
+
 	dais = <&rsnd_port0	/* ak4613 */
-		&rsnd_port1	/* HDMI0  */
-		&rsnd_port2	/* pcm3168a playback */
-		&rsnd_port3	/* pcm3168a capture  */
+//		&rsnd_port1	/* HDMI0  */
+		&rsnd_port2	/* pcm3168a playback	1ch/2ch */
+		&rsnd_port3	/*			3ch/4ch */
+		&rsnd_port4	/*			5ch/6ch */
+		&rsnd_port5	/*			7ch/8ch */
+		&rsnd_port6	/* pcm3168a capture	1ch/2ch */
+		&rsnd_port7	/*			3ch/4ch */
+		&rsnd_port8	/*			5ch/6ch */
 		>;
 };

Peter Ujfalusi Feb. 17, 2020, 12:09 p.m. UTC | #14

Hi Tony,

On 14/02/2020 19.03, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [200214 12:42]:
>> Hi Tony,
>>
>> On 12/02/2020 16.35, Tony Lindgren wrote:
>>> * Peter Ujfalusi <[e-mail]> [200212 08:02]:
>>>>
>>>>
>>>> On 11/02/2020 19.16, Tony Lindgren wrote:
>>>>> 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.
>>>>
>>>> It is still one DAI...
>>>> If you have multiple codec connected to the same I2S lines, but the
>>>> codecs communicate within different time slots, you still have one DAI
>>>> on the CPU side, but multiple codecs (codec DAIs) with different TDM slot.
>>>
>>> OK so subject should say "dodec DAIs" then I guess?
>>>
>>>>> See Documentation/devicetree/bindings/sound/audio-graph-card.txt and
>>>>> Documentation/devicetree/bindings/graph.txt for more details for
>>>>> multiple endpoints.
>>>>
>>>> See the example for 'Multi DAI with DPCM' in audio-graph-card.txt
>>>> The PCM3168a have 2 DAIs: playback and capture, but you can have
>>>> multiple endpoints within a DAI.
>>>
>>> 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 {
>>>                                 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 {
>>>                                 reg = <1>;
>>>                                 dai-format = "dsp_a";
>>>                                 frame-master = <&cpcap_audio_codec1>;
>>>                                 bitclock-master = <&cpcap_audio_codec1>;
>>>                                 remote-endpoint = <&mot_mdm6600_audio_codec0>;
>>>                         };
>>>                 };
>>>         };
>>> };
>>
>> According to
>> Documentation/devicetree/bindings/sound/audio-graph-card.txt
>> it should be something like this:
>> &mcbsp3 {
>>         #sound-dai-cells = <0>;
>>         pinctrl-names = "default";
>>         pinctrl-0 = <&mcbsp3_pins>;
>>         status = "okay";
>>
>>         ports {
>> 		#address-cells = <1>;
>> 		#size-cells = <0>;
>>                 port@0 {
>> 			reg = <0>;
>>
>> 			cpu_dai3: endpoint@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 {
>> 				dai-format = "dsp_a";
>> 				frame-master = <&cpcap_audio_codec1>;
>> 				bitclock-master = <&cpcap_audio_codec1>;
>> 				remote-endpoint = <&mot_mdm6600_audio_codec0>;
>> 			};
>> 		};
>> 	};
>> };
> 
> Hmms so I only spot reg use at different level changing above. Well
> that's not according to Documentation/devicetree/bindings/graph.txt,
> the reg numbering is per endpoint.
> 
> Sounds like the we have the example not following graph.txt in
> Documentation/devicetree/bindings/sound/audio-graph-card.txt while
> the code is now behaving as in graph.txt.
> 
>> If you span out dummy DAIs got dai1+ then how you will get anything
>> working via endpoint1+?
>> There will be no ops for McBSP, so it is not going to do anything...
> 
> Eventually it could have ops though. For things like capture of the tdm
> slot data for recording audio call for example, I don't know how that's
> supposed to work though. I guess mcbsp could be the clock master too,
> and for those cases it would have ops.
> 
> 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.

> 
>>> 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?
>>
>> The audio-graph-card.txt example shows pcm3168a which have two DAIs,
>> one for playback and one for capture.
>>
>> I guess Morimoto-san can explain if he carries out of tree patches to
>> get the described setup working on top of mainline...
>>
>> But, no, based on the documentation I don't ;)
> 
> Sounds like audio-graph-card.txt is just out of sync with graph.txt
> as we do have several working examples?
> 
>>>>> 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?
>>
>> That's an option, yes, if we really need extra dummy McBSP DAIs at all,
>> again, let's hear from Morimoto-san or Mark.
> 
> Well it would not necessarily be a dummy mcbsp dai in all cases it seems
> to me. But yeah nothing for the second dai to do right now for droid4
> voice call as it's all between the modem and the pmic.
> 
>>>> We still have legacy support in
>>>> omap-twl4030.c
>>>> omap3pandora.c
>>>> osk5912.c
>>>> rx51.c
>>>>
>>>> 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.
>>
>> For some it should not be a big deal as they only boot in DT mode.
>> /me adds this to the TODO list.
> 
> OK
> 
>>>> 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.

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?

> Regards,
> 
> Tony
> 

- Péter

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

Tony Lindgren Feb. 17, 2020, 11:10 p.m. UTC | #15

* Peter Ujfalusi <[e-mail]> [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

Tony Lindgren Feb. 17, 2020, 11:36 p.m. UTC | #16

* Tony Lindgren <[e-mail]> [200217 23:10]:
> * Peter Ujfalusi <[e-mail]> [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)

Peter Ujfalusi Feb. 18, 2020, 12:43 p.m. UTC | #17

Hi Tony,

On 18/02/2020 1.10, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [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

Sebastian Reichel Feb. 18, 2020, 2:04 p.m. UTC | #18

Hi,

On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <[e-mail]> [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

Tony Lindgren Feb. 18, 2020, 2:19 p.m. UTC | #19

* Sebastian Reichel <[e-mail]> [200218 06:05]:
> Hi,
> 
> On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
> > * Sebastian Reichel <[e-mail]> [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

Peter Ujfalusi Feb. 18, 2020, 3:26 p.m. UTC | #20

On 18/02/2020 1.36, Tony Lindgren wrote:
> * Tony Lindgren <[e-mail]> [200217 23:10]:
>> * Peter Ujfalusi <[e-mail]> [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

Tony Lindgren Feb. 18, 2020, 3:28 p.m. UTC | #21

* Peter Ujfalusi <[e-mail]> [200218 12:44]:
> Hi Tony,
> 
> On 18/02/2020 1.10, Tony Lindgren wrote:
> > * Peter Ujfalusi <[e-mail]> [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

Tony Lindgren Feb. 18, 2020, 3:34 p.m. UTC | #22

* Peter Ujfalusi <[e-mail]> [200218 15:28]:
> 
> 
> On 18/02/2020 1.36, Tony Lindgren wrote:
> > * Tony Lindgren <[e-mail]> [200217 23:10]:
> >> * Peter Ujfalusi <[e-mail]> [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

Sebastian Reichel Feb. 18, 2020, 4:35 p.m. UTC | #23

Hi,

On Tue, Feb 18, 2020 at 06:19:05AM -0800, Tony Lindgren wrote:
> * Sebastian Reichel <[e-mail]> [200218 06:05]:
> > On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
> > > * Sebastian Reichel <[e-mail]> [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

Sebastian Reichel Feb. 18, 2020, 9:16 p.m. UTC | #24

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 <[e-mail]> [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

Peter Ujfalusi Feb. 20, 2020, 2:07 p.m. UTC | #25

On 18/02/2020 17.28, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [200218 12:44]:
>> Hi Tony,
>>
>> On 18/02/2020 1.10, Tony Lindgren wrote:
>>> * Peter Ujfalusi <[e-mail]> [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

Peter Ujfalusi Feb. 20, 2020, 2:15 p.m. UTC | #26

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

Tony Lindgren Feb. 20, 2020, 8:13 p.m. UTC | #27

* Peter Ujfalusi <[e-mail]> [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

Tony Lindgren Feb. 20, 2020, 8:15 p.m. UTC | #28

* Peter Ujfalusi <[e-mail]> [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

Sebastian Reichel Feb. 20, 2020, 8:47 p.m. UTC | #29

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

Peter Ujfalusi Feb. 21, 2020, 1:20 p.m. UTC | #30

Hi Tony,

On 20/02/2020 22.15, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [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

Peter Ujfalusi Feb. 21, 2020, 2:07 p.m. UTC | #31

Hi Tony,

On 20/02/2020 22.13, Tony Lindgren wrote:
> * Peter Ujfalusi <[e-mail]> [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

Tony Lindgren Feb. 21, 2020, 6:08 p.m. UTC | #32

* Peter Ujfalusi <[e-mail]> [200221 13:21]:
> Hi Tony,
> 
> On 20/02/2020 22.15, Tony Lindgren wrote:
> > * Peter Ujfalusi <[e-mail]> [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

Patch

diff --git a/sound/soc/ti/omap-mcbsp-priv.h b/sound/soc/ti/omap-mcbsp-priv.h
--- 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
--- 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>
@@ -1304,23 +1305,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",
@@ -1409,18 +1440,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;