TLV320ADCx140 audio adc with TX2

Hi David,

If the audio path is not configured correctly, then it is possible that the DAPM widget for the I2S will not be turned on and so you will not see the clocks running. The pinmux looks fine and so it must be a configuration or routing issue somewhere. This is a common problem with integrating new codecs.

Can you run the following script and send me the output?

#!/bin/bash

set -e
set -u

outfile="${HOME}/tegra-audio-debug.txt"

if [ -f "${outfile}" ]; then
    rm "${outfile}"
fi

alsactl store -f "${outfile}"

dapm_dirs=$(sudo find /sys/kernel/debug/asoc -type d -name dapm)

for dir in ${dapm_dirs}; do
    sudo find ${dir} -type f -exec echo {} \; -exec cat {} \; >> "${outfile}"
done

echo "Tegra audio debug info written to ${outfile}"

Thanks
Jon

Hi Jon,

I have uploaded the output of your script as tegra-audio-debug.log

Cheers,
David.

tegra-audio-debug.log (505.7 KB)

Hi David,

I took at look through the output and I can see that the ‘audio serial interface’ is disabled for the 4 ADCs. Can you try enabling these and then run the kernel ASoC tracing again to see if there is any output? Also re-run the debug script again so we can see how this changes the audio route.

$ amixer -c tegrasndt186ref sset "x CH1_ASI_EN" 1
$ amixer -c tegrasndt186ref sset "x CH2_ASI_EN" 1
$ amixer -c tegrasndt186ref sset "x CH3_ASI_EN" 1
$ amixer -c tegrasndt186ref sset "x CH4_ASI_EN" 1

Thanks
Jon

Thanks so much for taking a look at this Jon.

I did the following:

$ amixer -c tegrasndt186ref sset "x CH1_ASI_EN" on
$ amixer -c tegrasndt186ref sset "x CH2_ASI_EN" on
$ amixer -c tegrasndt186ref sset "x CH3_ASI_EN" on
$ amixer -c tegrasndt186ref sset "x CH4_ASI_EN" on

but, unfortunately, the kernel ASoC tracing was again empty after doing

$ echo 0 | sudo tee /sys/kernel/debug/tracing/trace
$ echo 0 | sudo tee /sys/kernel/debug/tracing/events/enable
$ echo 1 | sudo tee /sys/kernel/debug/tracing/tracing_on
$ echo 1 | sudo tee /sys/kernel/debug/tracing/events/asoc/snd_soc_dapm_widget_power/enable
$ arecord -D hw:tegrasndt186ref,0 -c 4 -r 48000 -f S32_LE cap.wav
$ sudo cat /sys/kernel/debug/tracing/trace

I have attached the new debug output here:
tegra-audio-debug.log (505.9 KB)

Hi David,

Can you also try enabling the DRE switches? It is not clear to me if these need to be enabled or not but the block diagram of the ADC does show the ADC output going through the Digital filters and DRE.

$ amixer -c tegrasndt186ref sset 'x DRE_ENABLE' on
$ amixer -c tegrasndt186ref sset 'x CH1_DRE_EN' on
$ amixer -c tegrasndt186ref sset 'x CH2_DRE_EN' on
$ amixer -c tegrasndt186ref sset 'x CH3_DRE_EN' on
$ amixer -c tegrasndt186ref sset 'x CH4_DRE_EN' on

If you can enable those in addition to the ASI enables and while the arecord is running, execute the debug script to dump all the settings.

Thanks
Jon

Hi David,

I also noticed that you have both ADMAIF1 and ADMAIF2 connected to I2S1 …

/sys/kernel/debug/asoc/tegra-snd-t186ref-mobile-rt565x/codec:tegra210-axbar/dapm/I2S1 RX
I2S1 RX: Off  in 0 out 0
 out  "I2S1" "ADMAIF2 Mux"
 out  "I2S1" "ADMAIF1 Mux"
 in  "static" "I2S1 Receive"

If you are using ADMAIF1 then disconnect ADMIF2 …

$ amixer -c tegrasndt186ref sset "ADMAIF2 Mux" None

Regards
Jon

Hi Jon,

So currently, I am doing:

amixer -c tegrasndt186ref sset “ADMAIF1 Mux” I2S1
amixer -c tegrasndt186ref sset “ADMAIF2 Mux” None

amixer -c tegrasndt186ref sset “x CH1_ASI_EN” on
amixer -c tegrasndt186ref sset “x CH2_ASI_EN” on
amixer -c tegrasndt186ref sset “x CH3_ASI_EN” on
amixer -c tegrasndt186ref sset “x CH4_ASI_EN” on

amixer -c tegrasndt186ref sset “x DRE_ENABLE” on
amixer -c tegrasndt186ref sset “x CH1_DRE_EN” on
amixer -c tegrasndt186ref sset “x CH2_DRE_EN” on
amixer -c tegrasndt186ref sset “x CH3_DRE_EN” on
amixer -c tegrasndt186ref sset “x CH4_DRE_EN” on

and then running the debug script while recording:

arecord -D hw:tegrasndt186ref,0 -c 4 -r 48000 -f S32_LE cap.wav

Output is attached:
tegra-audio-debug.log (506.3 KB)

I have also switched devkit boards on the slim chance that my I2S1 pins may not have been functioning. Still no joy! It’s also strange that I revisited my SGTL5000 setup, which is attached to a separate devkit board. When I run arecord on that, I see all the correct clock activity - even after commenting out snd_soc_dai_set_sysclk()!

Cheers,

David.

Hi David,

It appears that there is no route between the ‘x Capture’ and the ADC. Could you try adding the following to the route …

nvidia,audio-routing =
    "x MIC1P”, “x Mic”,
    “x MIC2P”, “x Mic”,
     “x MIC3P”, “x Mic”,
     “x MIC4P”, “x Mic”,
     “x Capture”, “x CH1_OUT”,
     “x Capture”, “x CH2_OUT”,
     “x Capture”, “x CH3_OUT”,
     “x Capture”, “x CH4_OUT”;

This time when you run the trace can you also add …

$ echo 0 | sudo tee /sys/kernel/debug/tracing/trace
$ echo 0 | sudo tee /sys/kernel/debug/tracing/events/enable
$ echo 1 | sudo tee /sys/kernel/debug/tracing/tracing_on
$ echo 1 | sudo tee /sys/kernel/debug/tracing/events/asoc/snd_soc_dapm_path/enable
$ echo 1 | sudo tee /sys/kernel/debug/tracing/events/asoc/snd_soc_dapm_widget_power/enable
$ arecord ...
$ sudo cat /sys/kernel/debug/tracing/trace

Thanks
Jon

Hi Jon,

OK - I did that and now I seem to get something the trace:

# tracer: nop
#
# entries-in-buffer/entries-written: 2/2   #P:4
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
         arecord-20956 [000] ....  1015.662446: snd_soc_dapm_path: *ADMAIF1 Transmit -> (direct) -> Capture 1
         arecord-20956 [000] ....  1015.662456: snd_soc_dapm_path: *ADMAIF1 Transmit -> (direct) -> ADMAIF1 Transmit-ADMAIF1 CIF Transmit

The new script output is here: tegra-audio-debug.log (506.5 KB)

Still no clocks on the scope and after a while of trying to record I get input/output errors as before (I should have mentioned that earlier perhaps). It seems to me there must be something wrong with my machine driver preventing the clocks rather than just a routing problem?

Thanks,

David.

Hi David,

Thanks. Yes that still does not look quite right, can you try …

    "x MIC1P”, “x Mic”,
    “x MIC2P”, “x Mic”,
     “x MIC3P”, “x Mic”,
     “x MIC4P”, “x Mic”,
     “x Capture”, “x CH1_ADC”,
     “x Capture”, “x CH2_ADC”,
     “x Capture”, “x CH3_ADC”,
     “x Capture”, “x CH4_ADC”;

Thanks
Jon

>  #####                                                    ###
> #     #  #    #   ####    ####   ######   ####    ####    ###
> #        #    #  #    #  #    #  #       #       #        ###
>  #####   #    #  #       #       #####    ####    ####     #
>       #  #    #  #       #       #            #       #
> #     #  #    #  #    #  #    #  #       #    #  #    #   ###
>  #####    ####    ####    ####   ######   ####    ####    ###

It works! (or at least it appears to for now). I can see FSYNC at 48kHz, BCLK at around 6.144 MHz and four channels of 32-bit data on I2S1 DIN. I don’t know what MCLK is because the device PLL is generating it internally. Here are some scope traces:


The trace file is here: trace.log (37.1 KB) and the debug script output is here: tegra-audio-debug.log (506.5 KB).

I’m going to try to have a look at the data now to see what I’m actually getting, but as the EVM only has a microphone on input 1, and the first data packet seems to have more no-zero bits than the next three, I’d say things look promising. I’ll let you know how I go shortly.

Thanks again Jon,
You’re a genius.

Hello again John,

I’m wondering what the best way of storing all that configuration is between boots.
Presumably there is a config somewhere?

Cheers,

David.

Hi David,

Yes, please take a look at …

/usr/share/alsa/init/postinit/01-tegra-rt565x.conf

You should be able to create something similar for this ADC. After flashing the board for the first time, the ALSA mixer state (located in /var/lib/alsa/asound.state) does not exist and so these init scripts will be executed. On the first reboot the ALSA restore service will save the state to /var/lib/alsa/asound.state and then on subsequent boots it will restore the state. So if you have set the mixer state once and reboot, on the next reboot the state should be restored. However, it is best to have the initial state you want set by the init script as highlighted above so that everytime you flash the board, you do not need to manually set the default state.

Also once you have your init script, you should be able to execute the following command anytime to run it and reset the state …

$ alsactl init tegrasndt210ref 

If you run the above command now, you should see the print in …

/usr/share/alsa/init/postinit/00-tegra.conf

Regards,
Jon