* 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