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

14 Feb 2020


      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

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

Sebastian Reichel