[TAS2557 / TAS2563] Implement driver from kernel source

mateusz,
Just got this issue in my radar, Please give me sometime to go through the details before commenting on the possible solution.

Hello Mkumard,

I have custom board for Jetson Nano production module (with eMMC memory on SODIMM). On custom board is audio amplifier TAS2110 (in future TAS2563, which is replacement).
Hardware connection:

Jetson Nano pin TAS2110 pin name
226 SBCLK
224 FSYNC
220 SDIN
222 SDOUT
234 SDA
232 SCL
216 SDZ
97 IRQ

Hardware connection was verified used manually script to configuration amplifier and used below amixer command:
amixer -c tegrasndt210ref cget name=‘I2S3 Mux’
amixer -c tegrasndt210ref cset name=‘MVC1 Mux’ ADMAIF2
amixer -c tegrasndt210ref cset name=‘MVC1 Vol’ 11000
speaker-test -D hw:tegrasndt210ref,1 -c 1 -r 16000 -F S16_LE -t sine -f 1000
So hardware is fine.
After this step I started implementation driver in kernel 4.9.253.
I have driver for audio amplifier form TI.com (TAS2XXX-DRIVERS Driver or library | TI.com, driver support both ICs).
I still work on this topic and I made progress in implementation. Actually, I see sound card. Now problem is with nvidia,audio-routing. I tried few options but still error apear. Can you help me with correct settings?

Few debug logs:
$sudo zcat /proc/config.gz | grep CONFIG_SND_SOC_TAS2505
CONFIG_SND_SOC_TAS2505=y
$ sudo cat /proc/asound/cards
0 [tegrahda ]: tegra-hda - tegra-hda
tegra-hda at 0x70038000 irq 82
1 [tegrasndt210ref]: tegra-snd-t210r - tegra-snd-t210ref-mobile-TAS2xx
tegra-snd-t210ref-mobile-TAS2xxx_AMP
$sudo zcat /proc/config.gz | grep CONFIG_SND_SOC_SPDIF
CONFIG_SND_SOC_SPDIF=y

Below are files which I modified and dmesg log.
tegra_machine_driver_mobile.c (22.1 KB)
tegra210-porg-gpio-p3448-0002-b00.dtsi (2.1 KB)
tegra210-porg-p3448-common.dtsi (21.1 KB)
tegra210-porg-pinmux-p3448-0002-b00.dtsi (38.2 KB)
tas2505.h (3.2 KB)
tas2505.c (22.1 KB)
dmesg_log.txt (88.4 KB)

Thanks for your summary. I will review the recent info and revert back soon.

mateusz,
Below error seen on dmesg log
[ 1.960703] tegra-asoc: sound: ASoC: no source widget found for x OUT
[ 1.967167] tegra-asoc: sound: ASoC: Failed to add route x OUT → direct → x Headphone

Please try below fix for the above issue in file tegra210-porg-p3448-common.dtsi inside sound node.

	nvidia,audio-routing =
		"x Headphone",	"x Speaker";

Thank you for reply.
I changed routing as you advice. Now above error doesn’t appear, but something else is wrong.
I use below command to test:
speaker-test -D hw:tegrasnd210ref,1 -c 1 -r 48000 -t sine -f 1000
I check on oscilloscope and I2S (FS, CLK, DATA) signal appear, enable pin for amplifier is in correct state. In dmesg -follow doesn’t show anything when I use speaker-test.
Below is full dmesg log and sound card list
dmesg_full.txt (87.7 KB)
sound_card_list.txt (259 Bytes)
Do you have idea what is wrong?

Hi Mateusz,
Can you confirm whether all the Codec related mixer controls are set like unmute, volume etc… As there is a I2S signal out, this confirms DAPM path is proper and data is sent out to codec.

Also why “-c 1” is set for I2S format?. even the basic I2S mode operates on 2 channels. can you try with -c 2

I set"-c 1" in speaker-test, because I use mono channel. When I used “-c 2” amplifier didn’t work too (in dmesg quiet).
In Linux GUI sound settings I tested sound card, but on I2S line was quiet.
In command line I set volume via “amixer -c tegrasnd210ref cset name=‘MVC1 Vol’ 11000” but situation is the same - amplifier doesn’t generate sound.
What worries me is lack of clock on list (during speaker_test:
$ sudo grep -r aud_mclk /sys/kernel/debug/clk/clk_summary
I check also tracing during use speaker_test:
Display_tracing_trace_speaker_test_C2.txt (17.4 KB)
Display_tracing_trace_speaker_test_C1.txt (6.1 KB)

Hi Mateusz,
From the recent behavior, The Speaker-test should be able to send out audio samples on the Terga I2S DOUT signals. Can you try probing the same with oscilloscope if possible?.

Also MVC controls tried will be effective only if MVC module included into the playback path. Can you list the various mixer controls used before playback?.

Please dump and attach the output of “cat /sys/kernel/debug/clk/clk_summary” to check on the clock values during playback.

Screenshots from oscilloscope:
speaker-test -D hw:tegrasnd210ref,1 -c 1 -r 48000 -t sine -f 1000


speaker-test -D hw:tegrasnd210ref,1 -c 2 -r 48000 -t sine -f 1000

List of mxiers I2S3:
I2S3_mixers_list.txt (1.3 KB)
clk_summary:
clk_summary_full.txt (56.7 KB)
I see, that some problem is in clock connection, because on above list is clock named i2s2 is enable and rate is the same like on oscilloscope. Unfortunately tas2505-mclk is disable (the rate value is what I want).

Hi Mateusz,
From Clock summary log, I see all clocks are fine
pll_a 2 2 368639843 368640000 0 0
*[ default_freq 0]
pll_a_out0_div 1 1 49151980 61440000 0 0
*[ default_freq 0]
pll_a_out0 3 3 49151980 49152000 0 0
*[ default_freq 0]
i2s4 0 0 49151980 11289600 0 0
*[ default_freq 0]
i2s3 0 0 49151980 11289600 0 0
*[ default_freq 0]
i2s2 1 1 1536000 1536000 0 0
*[ default_freq 0]
i2s1 0 0 49151980 11289600 0 0
*[ default_freq 0]
i2s0 0 0 49151980 11289600 0 0
*[ default_freq 0]
extern1 3 3 12287995 12288000 0 0
*[ default_freq 0]

“extern1” is the MCLK clock going out for codec from Tegra. I hope you connected this MCLK clock from 40 pin header(7th pin) to codec MCLK?.

Even the I2S probe signals looks good w.r.t to frequency and there is some variation in the DOUT signals too on the screenshot attached.

Can you just try with below commands for audio playback. Avoiding MVC on the path. Please include if any codec specific controls required to be set.

amixer -c tegrasndt210ref cset name=“I2S3 Mux” “ADMAIF1”
speaker-test -D hw:tegrasnd210ref,0 -c 1 -r 48000 -t sine -f 1000

From Tegra perspective, the I2S signals are going out. May be you can cross check on the codec settings.

““extern1” is the MCLK clock going out for codec from Tegra. I hope you connected this MCLK clock from 40 pin header(7th pin) to codec MCLK?.”
No, I don’t use eval kit and I2S4, which is used on 40pin header.
My hardware use I2S3 and pins descripted in post #24 (dts files about gpio and pinmux are the same like I’m using now)

Hi Mateusz,
Yes, I understand you are using I2S3(pins 220, 222, 224,226). My question was related to Codec MCLK clock path. I like to know how you connected Codec MCLK pin to Tegra external clock.

Are you using Tegra MCLK (Pin 211) for codec clocking logic?.

This pin is floating (no connected to this). This is my first implementation I2S solution.
Can I set internal clock to MCLK?

Hi Mateusz,
Understood, The problem seems to be with MCLK connection.

On codec driver { TAS2505_CLKMUX, 0x00 } is the default value for MCLK clock mux in codec, the value #define “TAS2505_PLL_CLKIN_MCLK 0” indicates clock mux is set to external mclk clock source. we need to provide external MCLK clock source to codec(pin16 on codec) for its clocking logic.

Can you try connecting the Tegra Pin 211 (this needs pinmux change to make is SFIO) to Codec Pin 16 for MCLK source for codec. Also you need to call “snd_soc_dai_set_sysclk” with required MCLK source flag and MCLK freq in Machine driver. you can refer other codec implementation for this in tegra_machine_driver_mobile.c

For experiment:
{ TAS2505_CLKMUX, 0x07 } , you can set MCLK MUX source default value to 7 which will configure by default for BCLKIN. This might help in avoiding MCLK connection as mentioned above.

Hello,
Unfortunately second solution didn’t resolve my problem. Below is clk_summary:
clk_summary_clkmux7.txt (56.7 KB)
I tried made first advice:

  1. I set pin 211 as sfio:
    source/public/hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-porg-p3448-common.dtsi
    gpio@6000d200 {
    gpio_default_I2S: default {
    gpio-to-sfio = <32 33 34 35 216>;
    };
    };
  2. Deleted TEGRA_GPIO(BB, 0) from gpio-input in file tegra210-porg-gpio-p3448-0002-b00.dtsi
  3. Set call function snd_soc_dai_set_sysclk(rtd->codec_dai, TAS2505_PLL_CLKIN_MCLK, 12288000, SND_SOC_CLOCK_IN); in file tegra_machine_driver_mobile.c
  4. Set in file tas2505.c { TAS2505_CLKMUX, 0x00 }
    After these changes, when I use test sound from Linux GUI, I see signals on oscilloscope but still frequency sclk is incorrect. What is interesting, that when I use youtube as source then sclk is 1.411MHz and fsck 44kHz, but when source is test speaker from Linux GUI then sclk is 1.536MHz and fsck 48kHz
    clk_summary:
    clk_summary_clkmux0.txt (56.7 KB)
    tegra_machine_driver_mobile.c (22.1 KB)

Hi Mateusz,

still frequency sclk is incorrect.
For 48KHz, 2ch, 16bit sclk should be 1.536MHz, Youtube is playing 44.1KHz song so the clock is expected too on that line. So this seems correct from the clock log. Don’t see issue in clock or I2S signals.

Did you tried with aplay or speaker-test command line tool to play on codec?. The reason is for playing on Ubuntu GUI, you might need to add support for the codec in ALSA conf file. Also please check if any of the codec specific mixer control needs to be set.

Ok, so we will focus on aplay or speaker-test as source of sound.
I used command to test: speaker-test -D hw:tegrasnd210ref,0 -c 1 -r 48000 -t sine -f 1000 and frequency of sclk is to high than I set 1.536MHz (fslk 48kHz)

How can I check if any of the specific codec mixer control is necessary? I added driver to kernel source as I mansion in post 24.

Yes, to start with we will focus on command line player, once playback works we can support from userspace config.

Try with option “-F S16_LE” for speaker-test, I hope without this it’s running 32bit samples which might result in high SCLK rate.

You might need to check with codec vendor on the required controls needed to be set for playback.

Can you also dump “amixer -c 1 contents” and attach the log here. Let me also take a look.

I tried added option -F S16_LE, but in previous call command it was set as default so it didn’t change anything. Logs from call this command:
speker_test_log.txt (517 Bytes)
Logs from call amixer -c 1 contents:
amixer_c1_contents.txt (139.0 KB)

Hi Mateusz,
speaker-test command looks fine.

Please try with below codec control
amixer -c tegrasndt210ref cset name=“x Speaker Amplifer Volume” 5

If still issue exists, then you might need to contact codec vendor as Tegra I2S is sending audio data to codec.