[alsa-devel] [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
We can have multiple connections on a single McBSP instance configured with audio graph card when using TDM (Time Division Multiplexing). Let's allow that by configuring dais dynamically.
See Documentation/devicetree/bindings/sound/audio-graph-card.txt and Documentation/devicetree/bindings/graph.txt for more details for multiple endpoints.
I've tested this with droid4 where cpcap pmic and modem voice are both both wired to mcbsp3. I've also tested this on droid4 both with and without the pending modem audio codec driver that is waiting for n_gsm serdev dependencies to clear.
Cc: Aaro Koskinen aaro.koskinen@iki.fi Cc: Arthur D. spinal.by@gmail.com Cc: Jarkko Nikula jarkko.nikula@bitmer.com Cc: Merlijn Wajer merlijn@wizzup.org Cc: Pavel Machek pavel@ucw.cz Cc: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Sebastian Reichel sre@kernel.org Signed-off-by: Tony Lindgren tony@atomide.com --- 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;
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 aaro.koskinen@iki.fi Cc: Arthur D. spinal.by@gmail.com Cc: Jarkko Nikula jarkko.nikula@bitmer.com Cc: Merlijn Wajer merlijn@wizzup.org Cc: Pavel Machek pavel@ucw.cz Cc: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Sebastian Reichel sre@kernel.org Signed-off-by: Tony Lindgren tony@atomide.com
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;elsedai->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;elsedai->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);
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Peter Ujfalusi peter.ujfalusi@ti.com [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
Hi,
On Wed, Feb 12, 2020 at 06:35:43AM -0800, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [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
* Sebastian Reichel sre@kernel.org [200214 00:35]:
On Wed, Feb 12, 2020 at 06:35:43AM -0800, Tony Lindgren wrote:
Yes this should follow the audio-graph-card.txt example. We end up with mcbsp3 dts node as below on droid4:
&mcbsp3 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&mcbsp3_pins>; status = "okay";
ports { mcbsp3_port: port@0 { #address-cells = <1>; #size-cells = <0>; cpu_dai3: endpoint@0 {cpu_dai3_cpcap
reg = <0>; dai-format = "dsp_a"; frame-master = <&cpcap_audio_codec1>; bitclock-master = <&cpcap_audio_codec1>; remote-endpoint = <&cpcap_audio_codec1>; }; cpu_dai_mdm: endpoint@1 {cpu_dai3_mdm
OK
reg = <1>; dai-format = "dsp_a"; frame-master = <&cpcap_audio_codec1>; bitclock-master = <&cpcap_audio_codec1>; remote-endpoint = <&mot_mdm6600_audio_codec0>; }; }; };};
That is pretty much the same as the 'Multi DAI with DPCM' example, with dne dai, and multiple endpoints. I think we still have just one port for one i2s transport on the mcbsp :)
Does the above look as what you would expect based on the binding?
I haven't had a look at this for quite some time. I suppose the cpcap voice DAI and the modem will also have two endpoints? So once the BT support is added it will looks like this [simplified]?
Well it will be even simpler, no need for extra endpoints at the codecs, see below.
&mcbsp3 { ports { port@0 { cpu_dai3_cpcap: endpoint@0 {}; cpu_dai3_modem: endpoint@1 {}; cpu_dai3_bt: endpoint@2 {}; }; }; };
But yes, bluetooth would be just added as above under mcbsp3.
&cpcap { ports { voice: port@1 { cpcap_voice_cpu: endpoint@0 {}; cpcap_voice_modem: endpoint@1 {}; cpcap_voice_bt: endpoint@2 {}; }; }; };
But above there's no need to add anything under cpcap, it still only has the same two endpoints as it already has. So it's just as specified in the graph binding, just the #address-cells, #size-cells and reg added:
cpcap_audio: audio-codec { #sound-dai-cells = <1>; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; cpcap_audio_codec0: endpoint { }; }; port@1 { reg = <1>; cpcap_audio_codec1: endpoint { }; }; };
Then the modem codec looks like this:
mot_mdm6600_audio: audio-codec { #address-cells = <1>; #size-cells = <0>; #sound-dai-cells = <1>;
port@0 { mot_mdm6600_audio_codec0: endpoint { remote-endpoint = <&cpu_dai_mdm>; }; }; };
&bluetooth { ports { port@0 { bt_dai_cpu: endpoint@0 {}; bt_dai_modem: endpoint@1 {}; bt_dai_cpcap: endpoint@2 {}; }; }; };
And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio above.
My guess is that only cpcap registers and clock rate needs to be changed for bluetooth audio BTW, so if somebody havs a bluetooth headset just do the following in Android:
# cpcaprw --all > /tmp/before configure bluetooth headset for audio in android and start playing some music or make a phone call ... # cpcaprw --all > /tmp/after stop playing music or phone call ... diff -u /tmp/before /tmp/after
The registers will be different for a bluetooth phone call and playing music.
I've tested this with droid4 where cpcap pmic and modem voice are both both wired to mcbsp3. I've also tested this on droid4 both with and without the pending modem audio codec driver that is waiting for n_gsm serdev dependencies to clear.
What this patch you effectively just creating dummy-dais on top of the real McBSP DAI.
Yes I think this is needed for snd-soc-audio-graph-card, and this allows configuring whatever is needed for the i2s slot. But maybe you have some better way of doing it in mind?
You also rename the DAIs, which might break ams-delta.
Oops, that's not good. So should we just keep the old naming if there's only one endpoint?
We still have legacy support in omap-twl4030.c omap3pandora.c osk5912.c rx51.c
also n810.c
OK
which will break with the renamed DAI. On the other hand I think the legacy support can be dropped from them.
I'm not sure what all that would take.
rx51 and omap-twl4030 override the hardcoded paths with DT information when DT is available (= always), so hardcoded paths do not matter at all and could simply be removed (the patch should also make DT mandatory).
For omap3pandora, n810 and osk5912 the hardcoded information seems to be used and there does not seem to be any soundcard DT node for them. I suppose it's a bit of work for those devices. n810 looks simple enough to just use simple-card.
OK I'll just keep the old naming if there's only one child node.
Regards,
Tony
Hi,
On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
- Sebastian Reichel sre@kernel.org [200214 00:35]:
On Wed, Feb 12, 2020 at 06:35:43AM -0800, Tony Lindgren wrote:
Yes this should follow the audio-graph-card.txt example. We end up with mcbsp3 dts node as below on droid4:
&mcbsp3 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&mcbsp3_pins>; status = "okay";
ports { mcbsp3_port: port@0 { #address-cells = <1>; #size-cells = <0>; cpu_dai3: endpoint@0 {cpu_dai3_cpcap
reg = <0>; dai-format = "dsp_a"; frame-master = <&cpcap_audio_codec1>; bitclock-master = <&cpcap_audio_codec1>; remote-endpoint = <&cpcap_audio_codec1>; }; cpu_dai_mdm: endpoint@1 {cpu_dai3_mdm
OK
reg = <1>; dai-format = "dsp_a"; frame-master = <&cpcap_audio_codec1>; bitclock-master = <&cpcap_audio_codec1>; remote-endpoint = <&mot_mdm6600_audio_codec0>; }; }; };};
That is pretty much the same as the 'Multi DAI with DPCM' example, with dne dai, and multiple endpoints. I think we still have just one port for one i2s transport on the mcbsp :)
Does the above look as what you would expect based on the binding?
I haven't had a look at this for quite some time. I suppose the cpcap voice DAI and the modem will also have two endpoints? So once the BT support is added it will looks like this [simplified]?
Well it will be even simpler, no need for extra endpoints at the codecs, see below.
&mcbsp3 { ports { port@0 { cpu_dai3_cpcap: endpoint@0 {}; cpu_dai3_modem: endpoint@1 {}; cpu_dai3_bt: endpoint@2 {}; }; }; };
But yes, bluetooth would be just added as above under mcbsp3.
[...]
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
* Sebastian Reichel sre@kernel.org [200214 13:05]:
On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio above.
My understanding is, that CPU is not involved for calls (except for setting up cpcap registers correctly). Basically McBSP3 should remain idle for a call and data goes directly from modem to cpcap. The same should work for modem <-> BT, except that CPCAP seems to always provide the clock. That would imply a direct link between modem and codec / BT?
Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during voice call though, I guess it should be doable since mcbsp is not the clock master :)
My guess is that only cpcap registers and clock rate needs to be changed for bluetooth audio BTW, so if somebody havs a bluetooth headset just do the following in Android:
# cpcaprw --all > /tmp/before configure bluetooth headset for audio in android and start playing some music or make a phone call ... # cpcaprw --all > /tmp/after stop playing music or phone call ... diff -u /tmp/before /tmp/after
The registers will be different for a bluetooth phone call and playing music.
I can provider register values once I find some time.
OK great.
Regards,
Tony
Hi,
On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
- Sebastian Reichel sre@kernel.org [200214 13:05]:
On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio above.
My understanding is, that CPU is not involved for calls (except for setting up cpcap registers correctly). Basically McBSP3 should remain idle for a call and data goes directly from modem to cpcap. The same should work for modem <-> BT, except that CPCAP seems to always provide the clock. That would imply a direct link between modem and codec / BT?
Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during voice call though, I guess it should be doable since mcbsp is not the clock master :)
My guess is that only cpcap registers and clock rate needs to be changed for bluetooth audio BTW, so if somebody havs a bluetooth headset just do the following in Android:
# cpcaprw --all > /tmp/before configure bluetooth headset for audio in android and start playing some music or make a phone call ... # cpcaprw --all > /tmp/after stop playing music or phone call ... diff -u /tmp/before /tmp/after
The registers will be different for a bluetooth phone call and playing music.
I can provider register values once I find some time.
[NI] Normal idle (no BT headset connected) [BI] Bluetooth idle (with BT headset connected) [BC] Bluetooth call in progress [NC] Normal call in progress (BT headset disabled)
[NI] => [BI] => [BC] => [NC] CPCAP_REG_VAUDIOC 0x0065 => 0x0065 => 0x0065 => 0x0025 CPCAP_REG_CC 0x0000 => 0x0000 => 0x6000 => 0x60df CPCAP_REG_CDI 0x0040 => 0x0000 => 0xaa40 => 0xae0a CPCAP_REG_SDAC -------------- 0x0000 -------------- CPCAP_REG_SDACDI -------------- 0x0004 -------------- CPCAP_REG_TXI 0x0804 => 0x0004 => 0x0000 => 0x0cc6 CPCAP_REG_TXMP 0x079c => 0x079c => 0x0400 => 0x0673 CPCAP_REG_RXOA 0x0000 => 0x0000 => 0x0001 => 0x0001 CPCAP_REG_RXVC 0x0d34 => 0x0d34 => 0x0000 => 0x0b2c CPCAP_REG_RXCOA 0x0000 => 0x0000 => 0x0000 => 0x0601 CPCAP_REG_RXSDOA 0x0000 => 0x0000 => 0x0600 => 0x0600 CPCAP_REG_RXEPOA -------------- 0x0400 -------------- CPCAP_REG_RXLL -------------- 0x0000 -------------- CPCAP_REG_A2LA -------------- 0x0030 -------------- CPCAP_REG_MIPIS1 -------------- 0x0000 -------------- CPCAP_REG_MIPIS2 -------------- 0x0000 -------------- CPCAP_REG_MIPIS3 -------------- 0x0000 -------------- CPCAP_REG_LVAB -------------- 0x0000 --------------
-- Sebastian
* Sebastian Reichel sebastian.reichel@collabora.com [200218 06:05]:
Hi,
On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
- Sebastian Reichel sre@kernel.org [200214 13:05]:
On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio above.
My understanding is, that CPU is not involved for calls (except for setting up cpcap registers correctly). Basically McBSP3 should remain idle for a call and data goes directly from modem to cpcap. The same should work for modem <-> BT, except that CPCAP seems to always provide the clock. That would imply a direct link between modem and codec / BT?
Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during voice call though, I guess it should be doable since mcbsp is not the clock master :)
My guess is that only cpcap registers and clock rate needs to be changed for bluetooth audio BTW, so if somebody havs a bluetooth headset just do the following in Android:
# cpcaprw --all > /tmp/before configure bluetooth headset for audio in android and start playing some music or make a phone call ... # cpcaprw --all > /tmp/after stop playing music or phone call ... diff -u /tmp/before /tmp/after
The registers will be different for a bluetooth phone call and playing music.
I can provider register values once I find some time.
[NI] Normal idle (no BT headset connected) [BI] Bluetooth idle (with BT headset connected) [BC] Bluetooth call in progress [NC] Normal call in progress (BT headset disabled)
[NI] => [BI] => [BC] => [NC]CPCAP_REG_VAUDIOC 0x0065 => 0x0065 => 0x0065 => 0x0025 CPCAP_REG_CC 0x0000 => 0x0000 => 0x6000 => 0x60df CPCAP_REG_CDI 0x0040 => 0x0000 => 0xaa40 => 0xae0a CPCAP_REG_SDAC -------------- 0x0000 -------------- CPCAP_REG_SDACDI -------------- 0x0004 -------------- CPCAP_REG_TXI 0x0804 => 0x0004 => 0x0000 => 0x0cc6 CPCAP_REG_TXMP 0x079c => 0x079c => 0x0400 => 0x0673 CPCAP_REG_RXOA 0x0000 => 0x0000 => 0x0001 => 0x0001 CPCAP_REG_RXVC 0x0d34 => 0x0d34 => 0x0000 => 0x0b2c CPCAP_REG_RXCOA 0x0000 => 0x0000 => 0x0000 => 0x0601 CPCAP_REG_RXSDOA 0x0000 => 0x0000 => 0x0600 => 0x0600 CPCAP_REG_RXEPOA -------------- 0x0400 -------------- CPCAP_REG_RXLL -------------- 0x0000 -------------- CPCAP_REG_A2LA -------------- 0x0030 -------------- CPCAP_REG_MIPIS1 -------------- 0x0000 -------------- CPCAP_REG_MIPIS2 -------------- 0x0000 -------------- CPCAP_REG_MIPIS3 -------------- 0x0000 -------------- CPCAP_REG_LVAB -------------- 0x0000 --------------
Great thanks! Care to do also a dump just playing music to on bluetooth headset at some point?
Regards,
Tony
Hi,
On Tue, Feb 18, 2020 at 06:19:05AM -0800, Tony Lindgren wrote:
- Sebastian Reichel sebastian.reichel@collabora.com [200218 06:05]:
On Fri, Feb 14, 2020 at 09:09:46AM -0800, Tony Lindgren wrote:
- Sebastian Reichel sre@kernel.org [200214 13:05]:
On Thu, Feb 13, 2020 at 05:34:54PM -0800, Tony Lindgren wrote:
And bluetooth would be similar to cpcap_audio and mot_mdm6600_audio above.
My understanding is, that CPU is not involved for calls (except for setting up cpcap registers correctly). Basically McBSP3 should remain idle for a call and data goes directly from modem to cpcap. The same should work for modem <-> BT, except that CPCAP seems to always provide the clock. That would imply a direct link between modem and codec / BT?
Yes the direct link is i2s. I'm ot sure if mcbsp can be idle during voice call though, I guess it should be doable since mcbsp is not the clock master :)
My guess is that only cpcap registers and clock rate needs to be changed for bluetooth audio BTW, so if somebody havs a bluetooth headset just do the following in Android:
# cpcaprw --all > /tmp/before configure bluetooth headset for audio in android and start playing some music or make a phone call ... # cpcaprw --all > /tmp/after stop playing music or phone call ... diff -u /tmp/before /tmp/after
The registers will be different for a bluetooth phone call and playing music.
I can provider register values once I find some time.
[NI] Normal idle (no BT headset connected) [BI] Bluetooth idle (with BT headset connected) [BC] Bluetooth call in progress [NC] Normal call in progress (BT headset disabled)
[NI] => [BI] => [BC] => [NC]CPCAP_REG_VAUDIOC 0x0065 => 0x0065 => 0x0065 => 0x0025 CPCAP_REG_CC 0x0000 => 0x0000 => 0x6000 => 0x60df CPCAP_REG_CDI 0x0040 => 0x0000 => 0xaa40 => 0xae0a CPCAP_REG_SDAC -------------- 0x0000 -------------- CPCAP_REG_SDACDI -------------- 0x0004 -------------- CPCAP_REG_TXI 0x0804 => 0x0004 => 0x0000 => 0x0cc6 CPCAP_REG_TXMP 0x079c => 0x079c => 0x0400 => 0x0673 CPCAP_REG_RXOA 0x0000 => 0x0000 => 0x0001 => 0x0001 CPCAP_REG_RXVC 0x0d34 => 0x0d34 => 0x0000 => 0x0b2c CPCAP_REG_RXCOA 0x0000 => 0x0000 => 0x0000 => 0x0601 CPCAP_REG_RXSDOA 0x0000 => 0x0000 => 0x0600 => 0x0600 CPCAP_REG_RXEPOA -------------- 0x0400 -------------- CPCAP_REG_RXLL -------------- 0x0000 -------------- CPCAP_REG_A2LA -------------- 0x0030 -------------- CPCAP_REG_MIPIS1 -------------- 0x0000 -------------- CPCAP_REG_MIPIS2 -------------- 0x0000 -------------- CPCAP_REG_MIPIS3 -------------- 0x0000 -------------- CPCAP_REG_LVAB -------------- 0x0000 --------------
Great thanks! Care to do also a dump just playing music to on bluetooth headset at some point?
AFAIK BT music is usually done via A2DP using the data connection, but I can get a register dump to make sure. I guess the more interesting bit would be to use BT headset for a VOIP call, which requires the headset profile being routed to the CPU.
-- Sebastian
Hi Tony,
On 12/02/2020 16.35, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [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:
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
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...
* Mark Brown broonie@kernel.org [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
On Fri, Feb 14, 2020 at 09:05:59AM -0800, Tony Lindgren wrote:
- Mark Brown broonie@kernel.org [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.
* Peter Ujfalusi peter.ujfalusi@ti.com [200214 12:42]:
Hi Tony,
On 12/02/2020 16.35, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [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:
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
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 kuninori.morimoto.gx@renesas.com 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 kuninori.morimoto.gx@renesas.com --- 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 */ >;
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 kuninori.morimoto.gx@renesas.com 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 kuninori.morimoto.gx@renesas.com --- 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 */ >; };
Hi Tony,
On 14/02/2020 19.03, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200214 12:42]:
Hi Tony,
On 12/02/2020 16.35, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [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:
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
* Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
I know it was discussed, but can not find the mail: Can you brief again on the audio connection?
Below is a link to a mailing list thread where Sebastian describes the audio connection:
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 tony@atomide.com [200217 23:10]:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Looks like only initializing only one mcbsp3 instance here instead of two will produce an oops as below.
I'm not sure how this is supposed to work for snd-soc-audio-graph-card with multipe endpoints connected to just one mcbsp dai instance?
Regards,
Tony
8< ------------------- Internal error: Oops: 805 [#1] PREEMPT SMP ARM snd_soc_del_component_unlocked+0xf4/0x110 ... [ 39.616027] Backtrace: [ 39.616149] [<bf3f6bc4>] (snd_soc_del_component_unlocked [snd_soc_core]) from [<bf3f8ff4>] (snd_soc_add_component+0x238/0x374 [snd_s) [ 39.616149] r7:00000002 r6:00000002 r5:ec9a0e78 r4:00000122 [ 39.678283] qmi_wwan 1-1:1.6: cdc-wdm1: USB WDM device [ 39.739074] [<bf3f8dbc>] (snd_soc_add_component [snd_soc_core]) from [<bf3f9180>] (snd_soc_register_component+0x50/0x60 [snd_soc_cor) [ 39.739074] r10:bf4582d0 r9:ec9d0840 r8:00000002 r7:00000002 r6:ec9d0640 r5:bf4584ac [ 39.800842] asoc-audio-graph-card soundcard: using device tree for GPIO lookup [ 39.808685] r4:eed52410 [ 39.862304] [<bf3f9130>] (snd_soc_register_component [snd_soc_core]) from [<bf4088b4>] (devm_snd_soc_register_component+0x54/0x90 [s) [ 39.862304] r7:ec9d0640 r6:bf4584ac r5:ec9d3040 r4:eed52410 [ 39.925048] qmi_wwan 1-1:1.6 wwan1: register 'qmi_wwan' at usb-4a064800.ohci-1, WWAN/QMI device, 2e:59:df:3f:4f:ef [ 39.984558] [<bf408860>] (devm_snd_soc_register_component [snd_soc_core]) from [<bf456fb8>] (asoc_mcbsp_probe+0x3e8/0x574 [snd_soc_o) [ 39.984558] r9:ec9d0840 r8:ec9f4000 r7:eed52410 r6:00000000 r5:eed52400 r4:ec9d0840 [ 39.984588] [<bf456bd0>] (asoc_mcbsp_probe [snd_soc_omap_mcbsp]) from [<c068475c>] (platform_drv_probe+0x58/0xa8) [ 39.984619] r10:00000000 r9:0000002e r8:bf459014 r7:00000000 r6:bf459014 r5:00000000 [ 40.044342] of_get_named_gpiod_flags: can't parse 'pa-gpios' property of node '/soundcard[0]' [ 40.051788] r4:eed52410 [ 40.100769] [<c0684704>] (platform_drv_probe) from [<c06820ac>] (really_probe+0x1ec/0x358)
On 18/02/2020 1.36, Tony Lindgren wrote:
- Tony Lindgren tony@atomide.com [200217 23:10]:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Looks like only initializing only one mcbsp3 instance here instead of two will produce an oops as below.
I'm not sure how this is supposed to work for snd-soc-audio-graph-card with multipe endpoints connected to just one mcbsp dai instance?
Regards,
Tony
8< -------------------
What is the kernel version? The context is missing... Who printed the line: dev_err(dev, "ASoC: Failed to register DAIs: %d\n", ret);
This is only possible if snd_soc_component_initialize() fail, which can only fail if snd_soc_component_unique_name() fails.
Internal error: Oops: 805 [#1] PREEMPT SMP ARM snd_soc_del_component_unlocked+0xf4/0x110
Not too helpful ;)
... [ 39.616027] Backtrace: [ 39.616149] [<bf3f6bc4>] (snd_soc_del_component_unlocked [snd_soc_core]) from [<bf3f8ff4>] (snd_soc_add_component+0x238/0x374 [snd_s) [ 39.616149] r7:00000002 r6:00000002 r5:ec9a0e78 r4:00000122 [ 39.678283] qmi_wwan 1-1:1.6: cdc-wdm1: USB WDM device [ 39.739074] [<bf3f8dbc>] (snd_soc_add_component [snd_soc_core]) from [<bf3f9180>] (snd_soc_register_component+0x50/0x60 [snd_soc_cor) [ 39.739074] r10:bf4582d0 r9:ec9d0840 r8:00000002 r7:00000002 r6:ec9d0640 r5:bf4584ac [ 39.800842] asoc-audio-graph-card soundcard: using device tree for GPIO lookup [ 39.808685] r4:eed52410 [ 39.862304] [<bf3f9130>] (snd_soc_register_component [snd_soc_core]) from [<bf4088b4>] (devm_snd_soc_register_component+0x54/0x90 [s) [ 39.862304] r7:ec9d0640 r6:bf4584ac r5:ec9d3040 r4:eed52410 [ 39.925048] qmi_wwan 1-1:1.6 wwan1: register 'qmi_wwan' at usb-4a064800.ohci-1, WWAN/QMI device, 2e:59:df:3f:4f:ef [ 39.984558] [<bf408860>] (devm_snd_soc_register_component [snd_soc_core]) from [<bf456fb8>] (asoc_mcbsp_probe+0x3e8/0x574 [snd_soc_o) [ 39.984558] r9:ec9d0840 r8:ec9f4000 r7:eed52410 r6:00000000 r5:eed52400 r4:ec9d0840 [ 39.984588] [<bf456bd0>] (asoc_mcbsp_probe [snd_soc_omap_mcbsp]) from [<c068475c>] (platform_drv_probe+0x58/0xa8) [ 39.984619] r10:00000000 r9:0000002e r8:bf459014 r7:00000000 r6:bf459014 r5:00000000 [ 40.044342] of_get_named_gpiod_flags: can't parse 'pa-gpios' property of node '/soundcard[0]' [ 40.051788] r4:eed52410 [ 40.100769] [<c0684704>] (platform_drv_probe) from [<c06820ac>] (really_probe+0x1ec/0x358)
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Peter Ujfalusi peter.ujfalusi@ti.com [200218 15:28]:
On 18/02/2020 1.36, Tony Lindgren wrote:
- Tony Lindgren tony@atomide.com [200217 23:10]:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Looks like only initializing only one mcbsp3 instance here instead of two will produce an oops as below.
I'm not sure how this is supposed to work for snd-soc-audio-graph-card with multipe endpoints connected to just one mcbsp dai instance?
Regards,
Tony
8< -------------------
What is the kernel version? The context is missing... Who printed the line: dev_err(dev, "ASoC: Failed to register DAIs: %d\n", ret);
Oh sorry, this was just a quick test with droid4-pending-v5.5 branch with only one mcbsp dai initialized.
This is only possible if snd_soc_component_initialize() fail, which can only fail if snd_soc_component_unique_name() fails.
Internal error: Oops: 805 [#1] PREEMPT SMP ARM snd_soc_del_component_unlocked+0xf4/0x110
Not too helpful ;)
Yeah I have not looked at it closer so far..
Regards,
Tony
... [ 39.616027] Backtrace: [ 39.616149] [<bf3f6bc4>] (snd_soc_del_component_unlocked [snd_soc_core]) from [<bf3f8ff4>] (snd_soc_add_component+0x238/0x374 [snd_s) [ 39.616149] r7:00000002 r6:00000002 r5:ec9a0e78 r4:00000122 [ 39.678283] qmi_wwan 1-1:1.6: cdc-wdm1: USB WDM device [ 39.739074] [<bf3f8dbc>] (snd_soc_add_component [snd_soc_core]) from [<bf3f9180>] (snd_soc_register_component+0x50/0x60 [snd_soc_cor) [ 39.739074] r10:bf4582d0 r9:ec9d0840 r8:00000002 r7:00000002 r6:ec9d0640 r5:bf4584ac [ 39.800842] asoc-audio-graph-card soundcard: using device tree for GPIO lookup [ 39.808685] r4:eed52410 [ 39.862304] [<bf3f9130>] (snd_soc_register_component [snd_soc_core]) from [<bf4088b4>] (devm_snd_soc_register_component+0x54/0x90 [s) [ 39.862304] r7:ec9d0640 r6:bf4584ac r5:ec9d3040 r4:eed52410 [ 39.925048] qmi_wwan 1-1:1.6 wwan1: register 'qmi_wwan' at usb-4a064800.ohci-1, WWAN/QMI device, 2e:59:df:3f:4f:ef [ 39.984558] [<bf408860>] (devm_snd_soc_register_component [snd_soc_core]) from [<bf456fb8>] (asoc_mcbsp_probe+0x3e8/0x574 [snd_soc_o) [ 39.984558] r9:ec9d0840 r8:ec9f4000 r7:eed52410 r6:00000000 r5:eed52400 r4:ec9d0840 [ 39.984588] [<bf456bd0>] (asoc_mcbsp_probe [snd_soc_omap_mcbsp]) from [<c068475c>] (platform_drv_probe+0x58/0xa8) [ 39.984619] r10:00000000 r9:0000002e r8:bf459014 r7:00000000 r6:bf459014 r5:00000000 [ 40.044342] of_get_named_gpiod_flags: can't parse 'pa-gpios' property of node '/soundcard[0]' [ 40.051788] r4:eed52410 [ 40.100769] [<c0684704>] (platform_drv_probe) from [<c06820ac>] (really_probe+0x1ec/0x358)
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi Tony,
On 18/02/2020 1.10, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Sure, but with the dummy dai it won't....
If I understand correctly the HW setup: McBSP2 -> CPCAP_hifi (only playback)
CPCAP_voice is the i2s clock master. McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via i2s lines.
In case of Voice call with analog mic/speaker only CPCAP_voice and MDM6600 is used. In case of Voice call with BT only MDM6600 and WL1285 is used (but CPCAP_voice must provide the clocks?) In case you would have any algorithm running on OMAP4 for the calls, then you will have McBSP3 inserted and used between MDM6600 and CPAC_voice/WL1285. Similarly, if you would like to tap in and record the data from the bus you will have McBSP3 enabled.
The simplest use cases you want to support: A. McBSP3 <-> CPCAP_voice (playback/capture) B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call) C. MDM6600 <-> WL1285 (BT voice call) D. McBSP3 <-> BT (VoIP?)
I would not bother with recording the call as you would need tom reconfigure the McBSP playback pin (is it even possible) as input to OMAP4, I think..
B/C is codec2codec, McBSP3 is not involved at all. A/D is when McBSP3 is used only.
Imho this can be represented as McBSP2: 1 port 1.1: to CPCAP_hifi
McBSP3: 1 port, 2 endpoint 2.1: to CPCAP_voice 2.2: to WL1285 CPCAP: 2 ports hifi: 3.1: to McBSP2 voice: 4.1: to McBSP3 4.2: to MDM6600 MDM6600: 2 ports 5.1: to CPAC_voice 5.2: to WL1285 WL1285: 2 ports 6.1: to McBSP3 6.2: to MDM6600
The machine driver should switch between the graph links based on the use case for the interconnected devices: A: 2.2 <-> 4.1 B: 4.2 <-> 5.1 C: 6.2 <-> 5.1 D: 2.2 <-> 6.1
Can a generic card provide such a functionality? In case of B/C you should not have a running stream imho. In all cases CPCAP_voice should be able to run the clocks on i2s, even if it is not used by the audio setup. Not sure if you can just turn Wl1285 as master, but it is possible that it is master, but silent when it is not used?
I'm not sure if we should span out dummy dais for endpoints within a port. Imho the port _is_ the dai. Different endpoints might use different TDM slots on the port (or the same slot, which makes them exclusive).
I know it was discussed, but can not find the mail: Can you brief again on the audio connection?
Below is a link to a mailing list thread where Sebastian describes the audio connection:
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 peter.ujfalusi@ti.com [200218 12:44]:
Hi Tony,
On 18/02/2020 1.10, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Sure, but with the dummy dai it won't....
Right. I'm not attached to the dummy dai, but looks like currently snd-soc-audio-graph-card won't work without it. And we potentially do need a place to configure TDM slot specific stuff for mcbsp.
If I understand correctly the HW setup: McBSP2 -> CPCAP_hifi (only playback)
CPCAP_voice is the i2s clock master. McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via i2s lines.
In case of Voice call with analog mic/speaker only CPCAP_voice and MDM6600 is used. In case of Voice call with BT only MDM6600 and WL1285 is used (but CPCAP_voice must provide the clocks?)
Yes my guess is cpcap voice is the clock master in that case. It should show up from the cpcap register dump from Android with audio playing to a bluetooth headset.
In case you would have any algorithm running on OMAP4 for the calls, then you will have McBSP3 inserted and used between MDM6600 and CPAC_voice/WL1285. Similarly, if you would like to tap in and record the data from the bus you will have McBSP3 enabled.
The simplest use cases you want to support: A. McBSP3 <-> CPCAP_voice (playback/capture) B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call) C. MDM6600 <-> WL1285 (BT voice call) D. McBSP3 <-> BT (VoIP?)
I would not bother with recording the call as you would need tom reconfigure the McBSP playback pin (is it even possible) as input to OMAP4, I think..
Oh, I think there are Android apps to do that though.. Never tried if they work on droid4. But if they do, doing a register dump of mcbsp3 would show up how it's configured.
B/C is codec2codec, McBSP3 is not involved at all. A/D is when McBSP3 is used only.
Imho this can be represented as McBSP2: 1 port 1.1: to CPCAP_hifi
McBSP3: 1 port, 2 endpoint 2.1: to CPCAP_voice 2.2: to WL1285 CPCAP: 2 ports hifi: 3.1: to McBSP2 voice: 4.1: to McBSP3 4.2: to MDM6600 MDM6600: 2 ports 5.1: to CPAC_voice 5.2: to WL1285 WL1285: 2 ports 6.1: to McBSP3 6.2: to MDM6600
The machine driver should switch between the graph links based on the use case for the interconnected devices: A: 2.2 <-> 4.1 B: 4.2 <-> 5.1 C: 6.2 <-> 5.1 D: 2.2 <-> 6.1
OK
Can a generic card provide such a functionality?
I think the link for the patches you posted is patching the snd-soc-audio-graph-card already?
In case of B/C you should not have a running stream imho. In all cases CPCAP_voice should be able to run the clocks on i2s, even if it is not used by the audio setup. Not sure if you can just turn Wl1285 as master, but it is possible that it is master, but silent when it is not used?
Yeah, no idea.. But that's easy to configure in the dts based on the graph bindings :)
I'm not sure if we should span out dummy dais for endpoints within a port. Imho the port _is_ the dai. Different endpoints might use different TDM slots on the port (or the same slot, which makes them exclusive).
Right. So right now it seems that for snd-soc-audio-graph-card needs the dummy dai, but it's unclear what would need to be changed to not use a dummy dai for mcbsp.
The dts snippets I posted earlier do follow the graph bindings as far as I know. But just to confirm, do you see any need to move things around there?
> I know it was discussed, but can not find the mail: > Can you brief again on the audio connection?
Below is a link to a mailing list thread where Sebastian describes the audio connection:
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
On 18/02/2020 17.28, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200218 12:44]:
Hi Tony,
On 18/02/2020 1.10, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Sure, but with the dummy dai it won't....
Right. I'm not attached to the dummy dai, but looks like currently snd-soc-audio-graph-card won't work without it.
The generic cards will link up a dummy dai/codec when it is needed by DPMC.
And we potentially do need a place to configure TDM slot specific stuff for mcbsp.
Yes, but you still have one port and one endpoint should not change the configuration which is already in used for the other endpoint.
If I understand correctly the HW setup: McBSP2 -> CPCAP_hifi (only playback)
CPCAP_voice is the i2s clock master. McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via i2s lines.
In case of Voice call with analog mic/speaker only CPCAP_voice and MDM6600 is used. In case of Voice call with BT only MDM6600 and WL1285 is used (but CPCAP_voice must provide the clocks?)
Yes my guess is cpcap voice is the clock master in that case. It should show up from the cpcap register dump from Android with audio playing to a bluetooth headset.
OK.
In case you would have any algorithm running on OMAP4 for the calls, then you will have McBSP3 inserted and used between MDM6600 and CPAC_voice/WL1285. Similarly, if you would like to tap in and record the data from the bus you will have McBSP3 enabled.
The simplest use cases you want to support: A. McBSP3 <-> CPCAP_voice (playback/capture) B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call) C. MDM6600 <-> WL1285 (BT voice call) D. McBSP3 <-> BT (VoIP?)
I would not bother with recording the call as you would need tom reconfigure the McBSP playback pin (is it even possible) as input to OMAP4, I think..
Oh, I think there are Android apps to do that though.. Never tried if they work on droid4. But if they do, doing a register dump of mcbsp3 would show up how it's configured.
I don't see how you could record the data from the line which is connected to McBSP_DX pin (the pin is output).
But I might be missing something.
B/C is codec2codec, McBSP3 is not involved at all. A/D is when McBSP3 is used only.
Imho this can be represented as McBSP2: 1 port 1.1: to CPCAP_hifi
McBSP3: 1 port, 2 endpoint 2.1: to CPCAP_voice 2.2: to WL1285 CPCAP: 2 ports hifi: 3.1: to McBSP2 voice: 4.1: to McBSP3 4.2: to MDM6600 MDM6600: 2 ports 5.1: to CPAC_voice 5.2: to WL1285 WL1285: 2 ports 6.1: to McBSP3 6.2: to MDM6600
The machine driver should switch between the graph links based on the use case for the interconnected devices: A: 2.2 <-> 4.1 B: 4.2 <-> 5.1 C: 6.2 <-> 5.1 D: 2.2 <-> 6.1
OK
Can a generic card provide such a functionality?
I think the link for the patches you posted is patching the snd-soc-audio-graph-card already?
Yes it does, but the functionality is there via custom machine drivers. What I afraid is that such a complex wiring as the Droid4 have it might be not possible to use a generic - fits everything - driver without making it a customized one ;)
Otho, if the only thing is the machine level DAPM switching and linking the paths then it might be relatively straight forward to extend the simple-card family.
In case of B/C you should not have a running stream imho. In all cases CPCAP_voice should be able to run the clocks on i2s, even if it is not used by the audio setup. Not sure if you can just turn Wl1285 as master, but it is possible that it is master, but silent when it is not used?
Yeah, no idea.. But that's easy to configure in the dts based on the graph bindings :)
Yep, indeed.
I'm not sure if we should span out dummy dais for endpoints within a port. Imho the port _is_ the dai. Different endpoints might use different TDM slots on the port (or the same slot, which makes them exclusive).
Right. So right now it seems that for snd-soc-audio-graph-card needs the dummy dai, but it's unclear what would need to be changed to not use a dummy dai for mcbsp.
Since simple-card family can and will connect up dummy dai/codec when needed based on the setup, I would look at that and make it do so.
The dts snippets I posted earlier do follow the graph bindings as far as I know. But just to confirm, do you see any need to move things around there?
It also states that a port is a physical port which can have multiple endpoints. But multiple endpoint != DAI. port == dai.
>> I know it was discussed, but can not find the mail: >> Can you brief again on the audio connection? > > Below is a link to a mailing list thread where Sebastian describes > the audio connection: > > https://lkml.org/lkml/2018/3/28/881
Thanks!
>> Do you have branch with working code? > > Yeah I have slightly older set of the patches in my droid4-pending-v5.5 > kernel.org git branch with voice calls working.
I think I should put my droid4 out and try to get it working... Do you have a link for dummies to follow to get started? ;)
Probably the easiest one to use right now is the Maemo-leste devuan based test image using v5.5 kernel + modem and audio patches:
https://leste.maemo.org/Motorola_Droid_4
Just use a decent speed micro-sd card rated "a1" for example.
Cool. Now I can dual boot the droid4 :D I needed to rewrite the /etc/shadow to get a known root password so I can log in.
Not sure if you mean password for the droid4-kexecboot or the Linux distro you installed..
It was for the maemo-leste. Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my reference image...
Gentoo cool :)
I've had good luck with just plain alpine armv7 edge, the package updates work very fast for a slow system. The musl stuff requires running stellarium with 3d acceleration in a minimal devuan or whatever chroot environment though for stellarium etc..
I see, I might go via the lazy route and take buildroot ;)
But for droid4-kexecboot, you can configure it to automatically download new kernels over wlan. There's some info on the machine specific password and how to configure wlan in the droid4-kexecboot buildroot commits here:
https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update the /boot/boot/boot.cfg to boot my kernel, right?
Yeah you can update kernels and modules over wlan from the distro(s) you have configured, and also from droid4-kexecboot as above.
I need to try droid4-kexecboot's wifi support then.
Yeah you need to configure wpa_supplicant.conf and wlan.conf or whatever it was called. And make sure you have copied the old stock v3.0.8 kernel wlan modules and firmware as mentioned in the droid4-kexecboot git readme and install files.
OK.
Oh, and also read about the flags you need to use for mkfs.ext4 if doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand all the new flags if you want a partition to be readable for the droid4-kexecboot bootloader. And also the all the old Android distros currently still stuck with the ancient v3.0.8 kernel :p
I see, thanks for the warning!
Regards,
Tony
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Peter Ujfalusi peter.ujfalusi@ti.com [200220 14:08]:
On 18/02/2020 17.28, Tony Lindgren wrote:
Right. I'm not attached to the dummy dai, but looks like currently snd-soc-audio-graph-card won't work without it.
The generic cards will link up a dummy dai/codec when it is needed by DPMC.
Not sure what should be fixed here..
And we potentially do need a place to configure TDM slot specific stuff for mcbsp.
Yes, but you still have one port and one endpoint should not change the configuration which is already in used for the other endpoint.
OK so what's the fix for snd-soc-audio-graph-card expecting a separate DAI then?
Oh, I think there are Android apps to do that though.. Never tried if they work on droid4. But if they do, doing a register dump of mcbsp3 would show up how it's configured.
I don't see how you could record the data from the line which is connected to McBSP_DX pin (the pin is output).
But I might be missing something.
Yeah I don't know either, but the pins we have muxed for mcbsp3 are:
/* 0x4a100106 abe_pdm_ul_data.abe_mcbsp3_dr ag25 */ OMAP4_IOPAD(0x106, PIN_INPUT | MUX_MODE1)
/* 0x4a100108 abe_pdm_dl_data.abe_mcbsp3_dx af25 */ OMAP4_IOPAD(0x108, PIN_OUTPUT | MUX_MODE1)
/* 0x4a10010a abe_pdm_frame.abe_mcbsp3_clkx ae25 */ OMAP4_IOPAD(0x10a, PIN_INPUT | MUX_MODE1)
/* 0x4a10010c abe_pdm_lb_clk.abe_mcbsp3_fsx af26 */ OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1)
Isn't the data receive there as mcbsp3_dr?
I think the link for the patches you posted is patching the snd-soc-audio-graph-card already?
Yes it does, but the functionality is there via custom machine drivers. What I afraid is that such a complex wiring as the Droid4 have it might be not possible to use a generic - fits everything - driver without making it a customized one ;)
Otho, if the only thing is the machine level DAPM switching and linking the paths then it might be relatively straight forward to extend the simple-card family.
Yeah or maybe it just needs to be handled directly in the cpcap, mdm6600 codec drivers?
Right. So right now it seems that for snd-soc-audio-graph-card needs the dummy dai, but it's unclear what would need to be changed to not use a dummy dai for mcbsp.
Since simple-card family can and will connect up dummy dai/codec when needed based on the setup, I would look at that and make it do so.
Oh so make simple-card spin up the dummy dai instead of mcbsp?
The dts snippets I posted earlier do follow the graph bindings as far as I know. But just to confirm, do you see any need to move things around there?
It also states that a port is a physical port which can have multiple endpoints. But multiple endpoint != DAI. port == dai.
I guess I'm getting really confused now.. Are you saying the dts needs to be changed too now?
Regards,
Tony
Hi Tony,
On 20/02/2020 22.13, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200220 14:08]:
On 18/02/2020 17.28, Tony Lindgren wrote:
Right. I'm not attached to the dummy dai, but looks like currently snd-soc-audio-graph-card won't work without it.
The generic cards will link up a dummy dai/codec when it is needed by DPMC.
Not sure what should be fixed here..
The ASoC core creates dummy codec and dummy dai. They can be used by machine drivers when there is a need for a dummy connection.
And we potentially do need a place to configure TDM slot specific stuff for mcbsp.
Yes, but you still have one port and one endpoint should not change the configuration which is already in used for the other endpoint.
OK so what's the fix for snd-soc-audio-graph-card expecting a separate DAI then?
If it expects separate DAI in place where you don't actually have a DAI then it should use the dummy dai.
Oh, I think there are Android apps to do that though.. Never tried if they work on droid4. But if they do, doing a register dump of mcbsp3 would show up how it's configured.
I don't see how you could record the data from the line which is connected to McBSP_DX pin (the pin is output).
But I might be missing something.
Yeah I don't know either, but the pins we have muxed for mcbsp3 are:
/* 0x4a100106 abe_pdm_ul_data.abe_mcbsp3_dr ag25 */ OMAP4_IOPAD(0x106, PIN_INPUT | MUX_MODE1)
/* 0x4a100108 abe_pdm_dl_data.abe_mcbsp3_dx af25 */ OMAP4_IOPAD(0x108, PIN_OUTPUT | MUX_MODE1)
/* 0x4a10010a abe_pdm_frame.abe_mcbsp3_clkx ae25 */ OMAP4_IOPAD(0x10a, PIN_INPUT | MUX_MODE1)
/* 0x4a10010c abe_pdm_lb_clk.abe_mcbsp3_fsx af26 */ OMAP4_IOPAD(0x10c, PIN_INPUT | MUX_MODE1)
Isn't the data receive there as mcbsp3_dr?
Yes, that's the one. _dx is the tx pin from McBSP pow.
I think the link for the patches you posted is patching the snd-soc-audio-graph-card already?
Yes it does, but the functionality is there via custom machine drivers. What I afraid is that such a complex wiring as the Droid4 have it might be not possible to use a generic - fits everything - driver without making it a customized one ;)
Otho, if the only thing is the machine level DAPM switching and linking the paths then it might be relatively straight forward to extend the simple-card family.
Yeah or maybe it just needs to be handled directly in the cpcap, mdm6600 codec drivers?
The cpcap driver should no nothing about mdm6600 or anything which is outside of it, similarly to mdm6600. The machine driver knows that in the driod4 you have McBSP2, McBSP3, CPCAP, MDM6600 and WL1285. It is the role of the machine driver to make these work together.
Right. So right now it seems that for snd-soc-audio-graph-card needs the dummy dai, but it's unclear what would need to be changed to not use a dummy dai for mcbsp.
Since simple-card family can and will connect up dummy dai/codec when needed based on the setup, I would look at that and make it do so.
Oh so make simple-card spin up the dummy dai instead of mcbsp?
Not really, we have dummy dai/codec from core, the machine driver should use them.
Just think about: what if you move the audio setup to a new board with am5 for example? You will have McASP in place of McBSP, so you will also patch it up to create dummy mcasp dais? What if you move the setup to Tegra or imx, or qc? Patch everything up to create dummy dais?
The dts snippets I posted earlier do follow the graph bindings as far as I know. But just to confirm, do you see any need to move things around there?
It also states that a port is a physical port which can have multiple endpoints. But multiple endpoint != DAI. port == dai.
I guess I'm getting really confused now.. Are you saying the dts needs to be changed too now?
In a graph the port is the DAI. We have only one port in McBSP and it is bi-directional (dr/dx pins + clk lines).
Usually you have one McBSP connected to one codec, graph is clean: port to port.
In droid4 the physical lines are connecting together the 4 ports: McBSP3, CPCAP_voice, MDM6600 and Wl1285, right? It is a web ;)
But you still have _one_ port on the McBSP3 and not three. I guess the endpoints are coming into picture at this point to represent that the port is connected to multiple ports. The endpoints should control the port which is their parent.
mcbsp3_port { reg = <0>; mcbsp3_ep0: endpoint0 { remote-endpoint = <&cpcap_voice_ep0>; }; mcbsp3_ep1: endpoint1 { remote-endpoint = <&dmd6600_ep0>; }; mcbsp3_ep2: endpoint2 { remote-endpoint = <&wl1285_ep0>; }; };
cpcap_voice_port { reg = <0>; cpcap_voice_ep0: endpoint0 { remote-endpoint = <&mcbsp3_ep0>; }; cpcap_voice_ep1: endpoint1 { remote-endpoint = <&dmd6600_ep1>;}; cpcap_voice_ep2: endpoint2 { remote-endpoint = <&wl1285_ep1>; }; };
Or something...
If the cpcap_voice_ep1 <-> dmd6600_ep1 link is enabled then the McBSP3 port is not, it is not part of the graph.
In any case you will need DPCM for this to work to push the needed parameters to the codecs in case of codec2codec connection.
Regards,
Tony
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi,
On Tue, Feb 18, 2020 at 02:43:19PM +0200, Peter Ujfalusi wrote:
On 18/02/2020 1.10, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200217 12:10]:
On 14/02/2020 19.03, Tony Lindgren wrote:
But right now in droid4 voice call case mcbsp is just the i2s transport, and everything happens betwee the modem and the cpcap pmic.
Iow you don't need McBSP DAI at all. If you would have added the dummy codec to McBSP !3 and use that, it would work in a same way, or to DMIC or McPDM...
The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
Hmm yeah I don't know if the cpcap codec on the same mcbsp needs mcbsp for voice call.
According to Sebastian sounds like mcbsp can be idle at that point.
But what about capture of voice call at the mcbsp from the TDM slot? In that case mcbsp would be active.
Sure, but with the dummy dai it won't....
If I understand correctly the HW setup: McBSP2 -> CPCAP_hifi (only playback)
CPCAP_voice is the i2s clock master. McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via i2s lines.
In case of Voice call with analog mic/speaker only CPCAP_voice and MDM6600 is used. In case of Voice call with BT only MDM6600 and WL1285 is used (but CPCAP_voice must provide the clocks?) In case you would have any algorithm running on OMAP4 for the calls, then you will have McBSP3 inserted and used between MDM6600 and CPAC_voice/WL1285. Similarly, if you would like to tap in and record the data from the bus you will have McBSP3 enabled.
The simplest use cases you want to support: A. McBSP3 <-> CPCAP_voice (playback/capture) B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call) C. MDM6600 <-> WL1285 (BT voice call) D. McBSP3 <-> BT (VoIP?)
Your description matches my understanding of the hardware setup.
I would not bother with recording the call as you would need tom reconfigure the McBSP playback pin (is it even possible) as input to OMAP4, I think..
B/C is codec2codec, McBSP3 is not involved at all. A/D is when McBSP3 is used only.
Imho this can be represented as McBSP2: 1 port 1.1: to CPCAP_hifi
McBSP3: 1 port, 2 endpoint 2.1: to CPCAP_voice 2.2: to WL1285 CPCAP: 2 ports hifi: 3.1: to McBSP2 voice: 4.1: to McBSP3 4.2: to MDM6600 MDM6600: 2 ports
I suppose you mean 1 port, 2 endpoints?
5.1: to CPAC_voice 5.2: to WL1285 WL1285: 2 ports
and here too?
6.1: to McBSP3 6.2: to MDM6600
The machine driver should switch between the graph links based on the use case for the interconnected devices: A: 2.2 <-> 4.1 B: 4.2 <-> 5.1 C: 6.2 <-> 5.1 D: 2.2 <-> 6.1
Can a generic card provide such a functionality?
I suppose in the end its a question if generic card can provide TDM support.
In case of B/C you should not have a running stream imho.
I would expect, that MDM6600 codec marks itself as running/stopped based on call state. That should enable DAPM widgets automatically when CPCAP_voice is routed to MDM6600?
In all cases CPCAP_voice should be able to run the clocks on i2s, even if it is not used by the audio setup. Not sure if you can just turn Wl1285 as master, but it is possible that it is master, but silent when it is not used?
I provided CPCAP registers for BT call, which should be enough to figure this out (I did not yet analyze the results myself).
I'm not sure if we should span out dummy dais for endpoints within a port. Imho the port _is_ the dai. Different endpoints might use different TDM slots on the port (or the same slot, which makes them exclusive).
Makes sense to me.
-- Sebastian
> I know it was discussed, but can not find the mail: > Can you brief again on the audio connection?
Below is a link to a mailing list thread where Sebastian describes the audio connection:
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
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
* Peter Ujfalusi peter.ujfalusi@ti.com [200220 14:16]:
On 18/02/2020 23.16, Sebastian Reichel wrote:
I suppose in the end its a question if generic card can provide TDM support.
Sure it can, but can it handle the switching between the paths based on use cases? There should be machine level DAPM widgets to kick codec2codec (MDM6600
- CPAC_voice for example) and also to make sure that when you switch
between them the system is not going to get misconfigured. Switching between CPAC and BT route during call? Not allowing VoIP while on call, etc.
Well I guess the key thing to check here is if it's enough to keep track of things in the cpcap codec driver. If cpcap is always involved, that should be sufficient.
Regards,
Tony
Hi Tony,
On 20/02/2020 22.15, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200220 14:16]:
On 18/02/2020 23.16, Sebastian Reichel wrote:
I suppose in the end its a question if generic card can provide TDM support.
Sure it can, but can it handle the switching between the paths based on use cases? There should be machine level DAPM widgets to kick codec2codec (MDM6600
- CPAC_voice for example) and also to make sure that when you switch
between them the system is not going to get misconfigured. Switching between CPAC and BT route during call? Not allowing VoIP while on call, etc.
Well I guess the key thing to check here is if it's enough to keep track of things in the cpcap codec driver. If cpcap is always involved, that should be sufficient.
The codec driver should keep track on what it can do, but should not start policing the outside world. The machine driver knows the connections and should tell the components on what to do.
Regards,
Tony
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
* Peter Ujfalusi peter.ujfalusi@ti.com [200221 13:21]:
Hi Tony,
On 20/02/2020 22.15, Tony Lindgren wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [200220 14:16]:
On 18/02/2020 23.16, Sebastian Reichel wrote:
I suppose in the end its a question if generic card can provide TDM support.
Sure it can, but can it handle the switching between the paths based on use cases? There should be machine level DAPM widgets to kick codec2codec (MDM6600
- CPAC_voice for example) and also to make sure that when you switch
between them the system is not going to get misconfigured. Switching between CPAC and BT route during call? Not allowing VoIP while on call, etc.
Well I guess the key thing to check here is if it's enough to keep track of things in the cpcap codec driver. If cpcap is always involved, that should be sufficient.
The codec driver should keep track on what it can do, but should not start policing the outside world. The machine driver knows the connections and should tell the components on what to do.
OK that makes senes to me. So I guess now the question is if we can maintain this state in snd-soc-audio-graph-card instead of needing a custom machine driver.
Regards,
Tony
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
participants (6)
-
Kuninori Morimoto -
Mark Brown -
Peter Ujfalusi -
Sebastian Reichel -
Sebastian Reichel -
Tony Lindgren