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

14 Feb 2020


      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