@kayccc It has been a couple of days since any reply, does spujar have a different type of schedule, he replies during USA time.
Does he need any more info from me? I am waiting on him.
It scares me when I don’t here anything back every day. Sometimes topics just go dead for no reason, and then get closed almost like no one knows the answer!
Terry
Hi Terry,
Sorry, I missed your notifications and I was OOO today (IST time). Also please note that I work in IST time and the only reason you would find my replies in US time is because I want to help you out.
You seem to have wrong clock parent for ‘aud_mclk’.
Can you use ‘pll_a_out0’ as parent for ‘aud_mclk’? Try below command as I mentioned before.
# echo pll_a_out0 > /sys/kernel/debug/bpmp/debug/clk/aud_mclk/parent
# cat /sys/kernel/debug/bpmp/debug/clk/aud_mclk/parent
I am attaching a ‘test.wav’ file, try playing this instead of ‘cheering.wav’ after changing ‘aud_mclk’ clock parent. Use the same aplay command as before and post your observations. Give me clock tree and kernel log dump. Capture clock tree dump after you start playback and capture kernel log after aplay finishes.
Thanks,
test.wav plays on the hdmi, used aplay to play it on my hardware no sound
attached clk.txt is the cat /sys/kernel/debug/clk/clk_summary > /tmp/clk.txt
clk.txt (33.7 KB)
Terry
I am still seeing pll_p_out0 as parent for aud_mclk.
Did you try setting the parent to pll_a_out0?
Also attach kernel log. I just want to see if you are hitting any errors during aplay. The test clip I gave has duration of 30 seconds. So aplay command should exit cleanly after 30 seconds.
I did this
echo pll_a_out0 > /sys/kernel/debug/bpmp/debug/clk/aud_mclk/parent
result is
cat /sys/kernel/debug/bpmp/debug/clk/aud_mclk/parent
pll_a_out0
this is tail -f /var/log/syslog while running the aplay test.wav
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.300690] [AK4637] ak4637_set_bias_level(1572)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.301170] [ak4637] ak4637_i2c_write: (addr,data)=(0, 40)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.301516] [AK4637] ak4637_set_bias_level(1572)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.301979] [ak4637] ak4637_i2c_write: (addr,data)=(0, 40)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.303050] [AK4637] ak4637_hw_params(1394)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.303572] [AK4637] ak4637_set_dai_mute mute[OFF]
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.304062] [ak4637] ak4637_i2c_write: (addr,data)=(7, 2)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.304434] [AK4637] ak4637_set_dai_mute(1614) ret 1
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.304447] ak4637 8-0012: ASoC: Failed to unmute: 1
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.310024] [ak4637] ak4637_i2c_write: (addr,data)=(1, 4)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.310952] [ak4637] ak4637_i2c_write: (addr,data)=(0, 44)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.311324] [AK4637] ak4637_spklo_event(1205)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.312288] [ak4637] ak4637_i2c_write: (addr,data)=(1, 6)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.312720] [AK4637] ak4637_spklo_event(1205)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.313216] [AK4637] ak4637_spklo_event wait=1msec
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.314716] [ak4637] ak4637_i2c_write: (addr,data)=(2, 86)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.315163] [AK4637] ak4637_set_bias_level(1572)
Oct 7 09:35:33 BaseSystem_0_10 kernel: [ 3418.315678] [ak4637] ak4637_i2c_write: (addr,data)=(0, 44)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.781132] [AK4637] ak4637_set_bias_level(1572)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.781629] [ak4637] ak4637_i2c_write: (addr,data)=(0, 44)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.782019] [AK4637] ak4637_spklo_event(1205)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.782982] [ak4637] ak4637_i2c_write: (addr,data)=(2, 6)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.784866] [ak4637] ak4637_i2c_write: (addr,data)=(1, 4)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.785250] [AK4637] ak4637_spklo_event(1205)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.786272] [ak4637] ak4637_i2c_write: (addr,data)=(0, 40)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.786696] [AK4637] ak4637_set_dai_mute mute[ON]
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.787187] [ak4637] ak4637_i2c_write: (addr,data)=(7, 22)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.805208] [AK4637] ak4637_set_dai_mute(1614) ret 1
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.805226] ak4637 8-0012: ASoC: Failed to mute: 1
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.810667] [ak4637] ak4637_i2c_write: (addr,data)=(1, 0)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.811217] [AK4637] ak4637_set_bias_level(1572)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.811698] [ak4637] ak4637_i2c_write: (addr,data)=(0, 40)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.812060] [AK4637] ak4637_set_bias_level(1572)
Oct 7 09:36:03 BaseSystem_0_10 kernel: [ 3448.812068] [ak4637] ak4637_i2c_write: (addr,data)=(0, 0)
No other messages other than ak4637 debug messages.
Terry
since the bpmp is needed changing, so will echo pll_a_out0 > /sys/kernel/debug/bpmp/debug/clk/aud_mclk/parent take effect without a reboot, so we need to look at changing the pinmux in the bpmp also right?
Terry
In the clock tree dump you should see now pll_a_out0 as parent for both aud_mclk and i2s1. You can confirm this.
Expected rates:
i2s1 → 1536000
aud_mclk → 12288000
From clock point of view things seem to be good. Since you don’t see any errors in kernel logs and aplay is exits cleanly. So we are getting closer.
Now we need to check if anything is missing on codec configuration or mixer control side. I am checking your codec driver and datasheet.
No pinmux change or reboot is necessary. The clock parent change stays and it should reflect in the clock tree dump.
found error in device tree, this is the new stuff in the clk summary
pll_a_out0 0 0 45158398 45158400 0 0
*[ default_freq 0]
aud_mclk 0 0 11289599 11289600 0 0
*[ default_freq 0]
Terry
so the clock summary while running aplay shows rate for aud_mck and i2s1 different, is this correct?
pll_a_out0 3 3 49151992 49152000 0 0
*[ default_freq 0]
aud_mclk 1 1 12287998 12288000 0 0
*[ default_freq 0]
dspk2 0 0 12287998 12288000 0 0
*[ default_freq 0]
dspk1 0 0 12287998 12288000 0 0
*[ default_freq 0]
dmic4 0 0 2730666 3072000 0 0
*[ default_freq 0]
dmic3 0 0 2730666 3072000 0 0
*[ default_freq 0]
dmic2 0 0 2730666 3072000 0 0
*[ default_freq 0]
dmic1 0 0 2730666 3072000 0 0
*[ default_freq 0]
i2s6 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s5 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s4 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s3 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s2 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s1 1 1 1535999 1536000 0 0
*[ default_freq 0]
ahub 2 2 49151992 49152000 0 0
*[ default_freq 0]
Terry
I don’t understand what you meant by device tree error? And when exactly you check above clocks?
Yes, the clocks look perfect. Please check the expected rate calculations I mentioned earlier and ho they depend on sample rate. And yes clock rate dumps should always be checked after running use case, because the clocks get set at runtime from the drivers.
I changed the device tree and now the pll_a has both the aud_mclk and i2s1
the clock summary while aplay is running shows aud_mclk and i2s1 with different numbers, is this correct?
pll_a_out0 3 3 49151992 49152000 0 0
*[ default_freq 0]
aud_mclk 1 1 12287998 12288000 0 0
*[ default_freq 0]
dspk2 0 0 12287998 12288000 0 0
*[ default_freq 0]
dspk1 0 0 12287998 12288000 0 0
*[ default_freq 0]
dmic4 0 0 2730666 3072000 0 0
*[ default_freq 0]
dmic3 0 0 2730666 3072000 0 0
*[ default_freq 0]
dmic2 0 0 2730666 3072000 0 0
*[ default_freq 0]
dmic1 0 0 2730666 3072000 0 0
*[ default_freq 0]
i2s6 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s5 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s4 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s3 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s2 0 0 2047999 1536000 0 0
*[ default_freq 0]
i2s1 1 1 1535999 1536000 0 0
*[ default_freq 0]
ahub 2 2 49151992 49152000 0 0
*[ default_freq 0]
So are there other pinmux’s that affect audio?
pinmux have been touch for the 4 registers and the aud_mclk.
So how to find what I have wrong in the amixer stuff?
this is what I did in the device tree to change the parent of aud_mclk
git diff sources/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi
diff --git a/sources/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi b/sources/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi
index b5e18f763…e23815ef2 100755
— a/sources/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi
+++ b/sources/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-platforms/tegra186-quill-common.dtsi
@@ -724,7 +724,7 @@
<&tegra_car TEGRA186_CLK_AUD_MCLK>;
assigned-clock-parents = <&tegra_car TEGRA186_CLK_PLLA>,
<&tegra_car TEGRA186_CLK_PLL_A_OUT0>,
<&tegra_car TEGRA186_CLK_PLLP_OUT0>;
<&tegra_car TEGRA186_CLK_PLL_A_OUT0>;
assigned-clock-rates = <0>, <0>, <12000000>;
resets = <&tegra_car TEGRA186_RESET_AUD_MCLK>;
reset-names = "extern1_rst";
terry
Now, can you make following change in device tree?
sound {
...
nvidia,audio-routing = "x Int Spk", "x SPKLO"; //replace this with earlier routing property you have
...
nvidia,dai-link-1 {
...
link-name = "ak4637-playback";
};
}
In tegra_machine_driver_mobile.c you can add following:
tegra_machine_dai_init() {
...
rtd = snd_soc_get_pcm_runtime(card, "ak4637-playback");
if (rtd) {
dai_params =
(struct snd_soc_pcm_stream *)rtd->dai_link->params;
dai_params->rate_min = srate;
dai_params->formats = (machine->fmt_via_kcontrol == 2) ?
(1ULL << SNDRV_PCM_FORMAT_S32_LE) : formats;
err = snd_soc_dai_set_sysclk(rtd->codec_dai, 0,
aud_mclk, SND_SOC_CLOCK_IN);
if (err < 0) {
dev_err(card->dev, "codec_dai clock not set\n");
return err;
}
}
...
}
And put a print in your codec driver to make sure following function gets called.
static int ak4637_set_mcki(struct snd_soc_codec *codec, int fs, int rclk)
{
u8 mode;
int mcki_rate;
akdbgprt("\t[AK4637] %s fs=%d rclk=%d\n", __func__, fs, rclk);
if ((fs != 0) && (rclk != 0)) {
mcki_rate = rclk/fs;
switch (mcki_rate) {
case 256:
mode = AK4637_CM_0;
break;
case 384:
mode = AK4637_CM_1;
break;
case 512:
mode = AK4637_CM_2;
break;
case 1024:
mode = AK4637_CM_3;
break;
default:
return -1;
}
snd_soc_update_bits(codec, AK4637_06_MODE_CONTROL2, AK4637_CM,
mode);
}
return 0;
}
I am expecting precisely ‘case 256’ to be called.
Please post your observations after this.
You can attach these driver files for me to cross check.
You need not worry about pinmux now. If you have oscilloscope, you can probe i2s and aud_mclk clock signals to double confirm you actually see the expected rates.
The codec amixer settings need to be reviewed. It would be difficult for me to comment on this. I am looking at the driver to see if I can provide some inputs. Ideally you should be checking this with codec vendor about the settings they prefer. But lets see if I can figure out something to see if anything is missing.
Yes, the change you made is correct.
found this when I compiled ak4637.c
CC sound/soc/codecs/ak4637.o
sound/soc/codecs/ak4637.c:1349:12: warning: ‘ak4637_set_mcki’ defined but not used -Wunused-function]
static int ak4637_set_mcki(struct snd_soc_codec *codec, int fs, int rclk)
^~~~~~~~~~~~~~~
Looks like a smoking gun?
Terry
Yes this could be a problem. Above function gets called from below.
static int ak4637_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
{
struct snd_soc_codec *codec = dai->codec;
struct ak4637_priv *ak4637 = snd_soc_codec_get_drvdata(codec);
u8 fs;
...
snd_soc_update_bits(codec, AK4637_06_MODE_CONTROL2, AK4637_FS, fs);
ak4637->fs2 = params_rate(params);
#if (!defined(PLL_16BICK_MODE) & !defined(PLL_32BICK_MODE) & !defined(PLL_64BICK_MODE) & !defined(PLL_MCLK_MODE))
ak4637_set_mcki(codec, ak4637->fs2, ak4637->rclk);
#endif
return 0;
}
Can you check if because of conditional check above, this never gets called?
If this is not getting included because of conditional configs, you can call function blindly for testing purpose. But I think right way to first check is which config is actually enabled.