How to set dynamic audio route for I2S3 ?

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Hi
I’m using TX2 on our custom carrier board with L4T R28.1.

And we use I2S3 to connect the external codec chip.

We keep the original dts file, and try to use dynamic audio route to playback the sound.

Followings are our commands :

amixer cset -c tegrasndt186ref name=“ADMAIF1 Mux” ‘I2S3’
amixer cset -c tegrasndt186ref name=“I2S3 Mux” ‘MVC1’
aplay -D hw:1,0 /usr/lib/libreoffice/share/gallery/sounds/space.wav

We that expect there are output signal on I2S3, but there are not.

I also check “/sys/kernel/debug/clk/clk_summary”, and the "enable cnt"for i2s3 is always 0.

How can I use dynamic audio routing for I2S3 ?

Thanks
Joe

#2

If you use default DTB file you only can verify the i2s signal by probe it even connect a external codec chip.
Try below command and probe it to check if any signal. Also check the pinmux this pin is really map to i2s3 bus.

amixer -c 1 sset "ADMAIF2 Mux" "ADMAIF3" // set the source of ADMAIF2 Mux as ADMAIF1
amixer -c 1 sset "I2S3 Mux" "ADMAIF3" // set the source of I2S1 Mux as ADMAIF1
aplay -Dhw:1,0 xxx.wav // play a wav file to ADMAIF1
#3

Hi ShaneCCC
Thanks for your reply.
But I don’t understand your commands.
why “set the source of ADMAIF2 Mux as ADMAIF1”, but the parameters are “ADMAIF2” and “ADMAIF3” ?
And “set the source of I2S1 Mux as ADMAIF1” , but the parameters are “IS1” and “ADMAIF3” ?

By the way, we want to use “I2S3” (the name for device tree i2s1~6)

Thanks
Joe

#4

Following should be the controls for data path (admaif -> mvc -> i2s3 -> external world)
amixer cset -c tegrasndt186ref name=“MVC1 Mux” ''ADMAIF1”
amixer cset -c tegrasndt186ref name=“I2S3 Mux” ‘MVC1’
aplay -D hw:1,0 /usr/lib/libreoffice/share/gallery/sounds/space.wav

Check if above helps.

#5

Hi ShaneCCC
Thanks for your reply.
Finally, we can get signal and play sound on I2S3 by using your commands and change “nvidia,audio-routing” property in device tree.

Following is “nvidia,audio-routing” which we changed in device tree:
nvidia,audio-routing =
“x Headphone”, “x OUT”,
“x IN”, “x Mic”,
“y Headphone”, “y OUT”,
“y IN”, “y Mic”,
“z IN”, “z OUT”,
“z Headphone” , “z Mic”, // add for i2s3
“m Headphone”, “m OUT”,
“m IN”, “m Mic”,
“n Headphone”, “n OUT”,
“n IN”, “n Mic”,
“o Headphone”, “o OUT”,
“o IN”, “o Mic”,
“a IN”, “a Mic”,
“b IN”, “b Mic”,
“c IN”, “c Mic”,
“d IN”, “d Mic”,
“e Headphone”, “e OUT”,
“e IN”, “e Mic”,
“d1 Headphone”, “d1 OUT”,
“d2 Headphone”, “d2 OUT”;

However, we add ““z Headphone” ,“z Mic”” to it.

In “Tegra ASoC Driver” document, it said “DAPM routes are initialized as established in nvidia,audio-routing property.”, so we just try and error to get the result.

Do you think our setting is correct ?
And can you please help to explain why it can operate ? what do “z Headphone” and “z Mic” mean ?
(I only know “z” is prefix name of “nvidia,dai-link-3”…)

Thanks
Joe

#6

Yes for loopback over i2s3 ‘z Headphone’ and ‘z Mic’ needs to be added.
But add above similar to following,
“e Headphone”, “e OUT”,
“e IN”, “e Mic”,

z Headphone and z Mic should be defined in machine driver.

These are dummy end points and are required for DAPM path completion.
Without DAPM path completion, the audio path wont be completer and does not trigger audio callback function.

#7

Hi ShaneCCC
Thanks for the information
As you mentioned, the correct working device tree settings are :
nvidia,audio-routing = “x Headphone”, “x OUT”, “x IN”, “x Mic”,
“y Headphone”, “y OUT”, “y IN”, “y Mic”,
“z Headphone”, “z OUT”, “z IN”, “z Mic”, // changed for i2s3
“m Headphone”, “m OUT”, “m IN”, “m Mic”,
“n Headphone”, “n OUT”, “n IN”, “n Mic”,
“o Headphone”, “o OUT”, “o IN”, “o Mic”,
“a IN”, “a Mic”,
“b IN”, “b Mic”,
“c IN”, “c Mic”,
“d IN”, “d Mic”,
“e Headphone”, “e OUT”, “e IN”, “e Mic”,
“d1 Headphone”, “d1 OUT”,
“d2 Headphone”, “d2 OUT”;

It should be “z Headphone”, “z OUT”, “z IN”, “z Mic”

And as you said, I also found “z Headphone” and “z Mic” are defined in Tegra machine driver :“sound/soc/tegra-alt/tegra_t210ref_mobile_rt565x_alt.c”.

By the way, usually should I write a new machine driver for the external codec ?

Actually, we got a machine driver source code from codec vendor, but it’s very different to “tegra_t210ref_mobile_rt565x_alt.c”, it doesn’t set any “snd_soc_dapm_widget” in the code.

Can you please give us some advice ?

Thanks
Joe

#8

Yes, you should develop new codec driver for your device.
It’s better consult with the Vendor to get support.

#9

Hi ShaneCCC
We will try to develop it

Thanks for your information
Joe

#10