Could you have a try with the debug patch(i2s_debug_prints_patch.txt) in attachment to check the call flow/variables for i2s bus. I think your code does not run into tegra210_i2s_hw_params to cause i2s bus outputs nothing during “aplay”.the following log is mine and could be a reference.
I assume that would be called by the underlying system, not by me, but what do I know. :-)
Where and how do I ensure this is called? Or where do I look to see what is going wrong? Maybe you could put a dump_stack() in there, but I suspect it’s deep in the ASoC mechanism.
putting the following log for you debug and can you share the dapm status during “aplay” by cat /sys/kernel/debug/asoc/tegra-snd-t210ref-mobile-rt565x/dapm/* (in your case, should be tegra-snd-t210ref)
In the device tree, please add the property name-prefix and modify audio-routing also.
We used name-prefix = “x”; in order to distinguish between different dai link names. The control names can be duplicated between various drivers like codec, machine, platform so in order to create unique names these prefix is use.
I had omitted the name-prefix because it kept giving me errors; I figured the names were unique enough. But your suggestion got me thinking that was kinda lame, so I went about fixing that. Turns out the name I had given the CODEC didn’t exactly match the name the CODEC gave itself, so when adding widgets it couldn’t find the prefix I indicated. Once I fixed that, the audio path became very clear, and a few mixer settings completed the route (the CODEC disabled all output by default). With that (and replacing a couple capacitors on our amp), output works!
We have added required DT properties and configuration. Still We are in same page like you were…
Not getting I2S Bit clock
In Power tree, vdd-1v8-audio-hv-bias is OFF by default
In tegra gpio config, Values are not configured as sfio
aplay/arecord throwing same error like You faced…
We could not understand Your fix clearly. Could You please explain the fix in detail which you have posted last. It would be helpful to proceed further development.
I don’t have a lot of time to fully describe things, but I can point you at something that was oddly important: the name of the CODEC in the device tree is not arbitrary, and must exactly match the name the driver chooses. Otherwise the driver cannot find the chip.
See the name in there? “tlv320aic32x4.0-0018@18” had to be formatted exactly like that. The ALSA code looks for the driver stanza by the name of the driver, so make sure yours matches. Your driver probably prints its name whenever it writes to the kernel log.
Also incredibly handy is to see the audio path created, as you’ll likely need to enable the outputs on your CODEC: mine were all off by default. To see them, I wrote the following wrapper script.
#!/bin/bash
set -eu -o pipefail
if ! which "${1:-}" > /dev/null; then
echo >&2 "usage: $0 command args..."
exit 2
fi
t=/sys/kernel/debug/tracing
# clear the trace
sudo bash -c "echo 0 > $t/tracing_on"
sudo bash -c "echo > $t/trace"
# enable ASoC tracing
sudo bash -c "echo 1 > $t/events/asoc/enable"
sudo bash -c "echo 0 > $t/events/asoc/snd_soc_reg_read/enable"
# trace a single invocation
sudo bash -c "echo 1 > $t/tracing_on"
"$@"
sudo bash -c "echo 0 > $t/tracing_on"
# filter out blank lines
sudo grep '\S' $t/trace > trace.log
# EOF
I called it “audio-trace.sh” and used it whenever I ran something like aplay. E.g., “./audio-trace.sh aplay sample.wav”.